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

[Richard Frith-Macdonald]

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:
> > The latest incarnation of my quest to resolve my issues, has me
> > convinced that if across the board "where to write defaults?" issue is
> > addressed the ideal process for discovering paths would go like this:
> >
> > 0) env vars - "Did the user configure the instance of this app?"
> > 1) static files - "Did the system maintainer configure the default
> > behavior of this app?" (.GNUsteprc does this to some extent)
> > 2) "happy defaults" - "App says, `I'm alone and frightened, what do I
> > do?`"
>
> This is what the NSPathUtilities patch does. It sorts out most of these
> issues.  Using that, absolutely _no_ environment variables are 
> required to be
> set. It does the (1) static files part by having a hard coded location 
> for
> the startup file. This is set during the build and is a design 
> decision to do
> it this way.

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.

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

> > > We also
> > > need to modify PATH and LD_LIBRARY_PATH etc to allow GNUstep programs
> > > to be
> > > simply run from the unix shell.
>
> Sort of. There are choices here.
> LD_LIBRARY_PATH is needed only if the libraries are put somewhere 
> other than
> the standard locations for the platform. For package maintainers this 
> isn't
> an issue because the libraries are supposed to go somewhere.
> PATH isn't so much of an issue. It can be circumvented by using a 
> launching
> tool which knows about GNUstep locations (either hard-coded or conf 
> file).
> That means you'll have to use something like:
> gslaunch Ink.app {for applications}
> gslaunch make_services {for tools}
> which really isn't so hard.
> There is also the possibility of adding sym-links into {whatever}/bin
> How it should be done is a packager choice for the platform.

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.

> > many ways to configure the GNUstep env in subtle ways is, well, a
> > bother to me, but potentially a bother to all users.
>
> The GNUstep env is a great thing if you know how it fits together. 
> Really,
> though, it should only be of concern to those wanting to build and run 
> -core
> in a sandbox.
>
> Here is the crunch.  Getting -make to behave properly in this scheme 
> requires
> a few modifications. Some of these should, IMHO, be made anyway 
> because there
> is currently a certain level of linkage between -make and the others 
> (-base,
> -gui, -back) which shouldn't be there. For example, you configure the 
> choice
> of back integration in make, not in -gui. Or that you choose your path 
> layout
> in -make instead of in -base.
>
> Currently, you configure the path layout you want for -base in -make. 
> Which
> causes all sorts of problems if you're trying to have multiple builds 
> on the
> same machine. You end up with multiple installations of -make 
> configured for
> the different sandboxes and sourcing various GNUstep.sh for each.
>
> I've gotten around that problem by having a gspath tool which can 
> discover the
> path correctly for the platform and can be told what path to use for a
> particular sandbox. (Okay, I'm doing that with an env var but that's 
> because
> there is no getopt on Win32 standard and importing existing code for 
> it is a
> licensing issue I don't want to deal with right now)

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.