Re: [GNUstep-packagers] patch for observance of $HOME

[Sheldon Gill]

On Sat, 7 Aug 2004 17:58, Richard Frith-Macdonald wrote:
> On 7 Aug 2004, at 10:20, Sheldon Gill wrote:
> > On Sat, 7 Aug 2004 16:24, Richard Frith-Macdonald wrote:
> >> On 7 Aug 2004, at 08:13, Sheldon Gill wrote:
> >>> On Fri, 6 Aug 2004 22:26, Armando Di Cianno wrote:
> >>>> On 2004-08-06 04:36:01 -0400 Richard Frith-Macdonald
> >>>>
> >>>> <richard@brainstorm.co.uk> wrote:
> >>>> [snip]
> >>
> >> I would not use such a system ... it's a strong requirement for
> >> rolling
> >> out systems
> >> for clients that the installed system be relocatable as I don't
> >> necessarily know
> >> where the client is going to install the software.  It's no use having
> >> my software
> >> relocatable if the gnustep package I bundle with it depends on
> >> hard-coded paths.
> >
> > If you choose not to use this element of the system, that's fine. (0)
> > uses the
> > environment variables. So it's not different to the current situation.
> > Note also that although the startup file is in a chosen location, the
> > actual
> > binary installation can go anywhere.  The startup file is a
> > configuration
> > file which has a well defined place to live on pretty much all
> > POSIX-ish
> > systems. Exactly where varies from OS to OS but that isn't so much of
> > an
> > issue. You can have the client install the software where ever they
> > want,
> > they just need to put the .conf file in one place. Same as currently
> > done
> > with a multitude of other *nix software.
>
> As long as the location of the startup file is not fixed at build time,
> it's fine to use a startup file (in fact my preferred option).
> It's also good to have a standard location defined at build time, as
> long as one is not forced to use it.
>
> eg.  The startup logic could run -
> 1. Try configured startup location... use it if present otherwise ...
> 2. Look for environment variable defining location of startup file.
>
> That way, on a system where you have root access, you can create
> a startup file in the standard location, thus *forcing* all users of
> GNUstep
> to use the information you supplied.
> On the other hand, where you don't have root access, you can set an
> environment variable to specify the location of your own GNUstep
> installation, as long as root has not put an overriding startup file in
> place.

I pretty much agree on this. The configured startup location has to be fixed 
at build time as I'm sure you appreciate. That's all I was saying. By "fixed 
at build time" I meant there is a path hard-coded into the binary. Of course 
the actual value is set by configure, preferably to sane defaults for the 
platform.

> >>> The (2) defaults are, again, set during the build phase.  There is
> >>> even
> >>> provision for the library to be built to go straight to (2), ie use
> >>> hard-code
> >>> only.  That is a good choice for a package on a fixed FS layout.
> >>> Under such
> >>> a system there is only one place for things to go and so no decisions
> >>> really
> >>> need to be made.
> >>
> >> But with clients who require easy to install relocatable binary
> >> packages,
> >> this scheme is no good at all ... as usual, a solution which is ideal
> >> for one purpose
> >> can easily be unusable for another.
> >
> > That's true. That is why there is a multi-step approach and why I've
> > included
> > additional build time configuration options. Choose the right scheme
> > for your
> > application.
>
> I haven't looked at these details but ... my preference would be for a
> scheme
> with *NO*  build time configuration options to be set.  This is to say,
> it would
> be best to have things work the same way on all systems and to have that
> one way be both simple and flexible enough to cover all requirements.

I don't see how you can have it flexible with *NO* build time configurations. 
You've got to provide sane defaults which differ by platform. I'm unaware of 
an alternative option. (There is no path discovery on *nix which is why *step 
implements one. Any why we have the path handling issues for -base ;)

I agree though, that the *mechanism* should be the same, relatively simple and 
flexible.

> >>>>> We also
> >>>>> need to modify PATH and LD_LIBRARY_PATH etc to allow GNUstep
> >>>>> programs
> >>>>> to be
> >>>>> simply run from the unix shell.
> >>>
> >>> [Snip]
> >>
> >> Yes ... but we need to provide a script to make the job easy for
> >> people
> >> who
> >> aren;t using pre-packaged installations where the job is done for
> >> them.
> >
> > Sure. I was pointing out some options with intention of highlighting
> > flexibility. Not advocating forcing everyone to pre-packaged
> > installations at
> > all. I do think, though, that pre-packaged will become the majority of
> > installations in time. That's been the case with lots of other
> > software.
> >
> >>>> many ways to configure the GNUstep env in subtle ways is, well, a
> >>>> [Snip]
> >
> >> I think the whole issue is easily solvable (as I mentioned in an
> >> earlier post) by
> >> having a single environment variable to define the root of the GNUstep
> >> installation
> >> and having make and base deduce all other information from that.
> >>
> > I disagree on this.  From a security and administrative view this
> > isn't an
> > acceptable solution for many installations.
>
> I'm not sure why you think this ... on a system where the administrator
> wants to have users locked down, s/he would control this by having the
> top level .GNUsteprc file override the default so providing complete
> control over the users, and on a system where users control their own
> GNUstep installations, the environment variable is secure ... unless
> someone has hacked in to their account or got them to run a trojan ...
> in which case all security for that user is already compromised.

The suggestion was having a single environment variable define the root. This 
would make the whole system easy to override by a user which would give rise 
to administrative and security issues.  If the library uses a preset location 
for the configuration first, then the env-var doesn't override admin which is 
IMHO the way it should be.

I think we're mostly agreed on the over-all scheme. A few details to be ironed 
out but that isn't so much of a thing:

1) Try config at build location
2) Try environment alternative config location
3) Try individual environment variables
4) Go to fallbacks

I'd advocate keeping (3) for the moment to provide backwards compatibility and 
consider deprecating it later.


Regards,
Sheldon