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

[Sheldon Gill]

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. 

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

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


Regards,
Sheldon