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

[Richard Frith-Macdonald]

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.

> > > 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.

> > > > > 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.