Re: GNUstep.sh / env sanity patches

[Armando Di Cianno]

I'm going to comment on my own needs for packaging / building in a 
sandbox, but these are specific needs, and not more important than 
what is "good for GNUstep." :-)

On 2004-08-17 14:14:10 -0400 Nicola Pero <nicola@brainstorm.co.uk> 
wrote:
> An additional requirement which often pops up is that the system 
> should
>
> * allow each user to put one's user domain and user defaults in the
> directory / location that they want.

This is especially important for two reasons, one specific, one 
"pissy."  First, if building a package, including building docs, 
attempts at no point to write Defaults / create the Defaults 
directory, then this first issue is moot.  However, if it does, I 
would definitely like to be able to "temporarily" point the Defaults 
dir somewhere else, i.e. in a place that does not write to the live / 
non-sandox filesystem.

Secondly, and maybe this is just me, but tools like gdomap, etc, 
should _never_ write (Defaults) into /root.  This may have been a side 
effect of sourcing GNUstep.sh / make_services being called, but if any 
daemons need defaults there should be a directory used with the feel 
of "/var/run/GNUstep", "/usr/GNUstep/System/run", or something to that 
effect.  I never want to find mysterious files in /root. ;-)  It's 
scary!

> Now there are some additional things to notice.
>
> 1. To support libraries and frameworks in the user domain, 
> LD_LIBRARY_PATH
> must be set each time the user logs in to include the user domain's
> library folder in the linker path (you can't set the global paths in
> ld.so.conf because every user needs different paths!).  This is in
> conflict with the "no startup scripts" requirements.  The conclusion 
> is
> that if you source no startup scripts, you won't be able to put 
> libraries
> and frameworks in the user domain.  To be able to do so, you'll still 
> need
> to source a script.

Is this always true?  If I have a framework/library in the user 
domain, and open application ABC with "openapp" (which is a shell 
script [atm]), why can it not set LD_LIBRARY_PATH to include 
"~/GNUstep/Library/LibNeededForABC" before launching the app?  I 
suppose if openapp was a C program it would have to use putenv() and 
fork() magic and such to set LD_LIBRARY_PATH and launch the app.

> 2. To compile stuff using gnustep-make you will always need the
> GNUSTEP_MAKEFILES environment variable set.  If we design the system
> properly that might be all you need to do.  I'd like that.

I'm okay with this as well.  The GNUmakefiles themselves should always 
utilize this env var if it is there as well ... to often, while trying 
to work around the problems I've been having, internal / source 
package GNUmakefiles would include other makefiles based on 
$GNUSTEP_SYSTEM_ROOT/Makefiles, which I was trying to re-route, and 
not GNUSTEP_MAKFILES.  Very frustrating.

> It would be nice to be able to pass the location of a different file:
>
> * on the command line as a special argument
>
> * as a shell variable

I support the 2nd more.  My best idea about this, I feel, was 
following a style like the following to get paths and such: env vars 
-> conf files -> happy defaults (./configure settings?).  Of course, 
the conf files should be able to "override" the env vars for 
GNUSTEP_SYSTEM_ROOT and such.

> Then if you want to have multiple installations, you can have them in
> different locations.  You run scripts to change PATHs, 
> LD_LIBRARY_PATHs,
> etc switching from one to the other.  Then you can also set a shell
> variable to tell tools to read a different GNUsteprc.  That only 
> applies
> to the crazy people who do those things with multiple installations 
> (ehm,
> I do, even if only for testing); for a single GNUstep installation 
> (all
> the rest of us including me when I'm not testing), there is a single
> GNUsteprc file in /etc (on linux) and nothing else needs to be done 
> -- no
> shell variable needs to be set, nothing.

Can we stick with keeping conf files somewhere in /usr/GNUstep/System? 
 This is set at compile time, and maintains GNUstep keeping it's own 
FHS, rather than the underlying system.  But this is just a minor 
point.

> Unfortunately, tricky bits abund.  The GNUsteprc file will implicitly
> specify, for example, where gnustep-base should look for basic files 
> such
> as character sets (if gnustep-base is installed in /usr/lib/ and the

... so I'm always a fan of configurability where it makes sense, but 
why are people installing bits of GNUstep all over the place?  I guess 
if it's possible, we should go for it, but I'm okay with the idea of 
viewing whatever the "core" libraries are at any moment as needing to 
be installed somewhere under /usr/GNUstep/System, or whatever was set 
at compile time.

> The GNUsteprc file would contain stuff like --
>
> GNUSTEP_SYSTEM_ROOT=/usr/GNUstep/System
> GNUSTEP_LOCAL_ROOT=/usr/GNUstep/Local
> GNUSTEP_NETWORK_ROOT=/usr/GNUstep/Network
>
> (the reason we still prefix those with GNUSTEP_ is that the file 
> *will* be
> included in makefiles and shell scripts, where we want to stay in our
> namespace).  I suppose any of those is optional but 
> GNUSTEP_SYSTEM_ROOT
> which is compulsory.

Please, please, please, if we can, support either "INSTALL_ROOT_DIR" 
or "GNUSTEP_INSTALLATION_DIR" for package building.  At every point 
where "installing" is taking place in the GNUmakefiles, if those 
settings are there, they should override GNUSTEP_SYSTEM_ROOT, but 
solely for the purposes of where make is going to tell the files to 
install themselves when "install" is called; nothing more, nothing 
less. :-) [another point that was driving me nuts lately ;-)]

> You might still need to source GNUstep.sh -- for example if you want 
> to
> install libraries / frameworks in your own user domain, even if you 
> are
> not interested in multiple installations.  I do like that.

I'm still okay with a "convenience" settings setter script like 
GNUstep.sh as long as it has no side effects.  Especially in regards 
to make_services.  In our HOWTO's we tell people to put "gpbs" in 
their xinitrc's, but we don't tell them to put make_services in their 
.bashrc's (or am I thinking .bash_profile ... whatever the login one 
is)?  That's pretty much all it would take, I assume/hope.

> Presumably if that's included in a shell script or in a makefile it 
> should
> work no matter which user is including it because it's using ~ for the
> user home directory.  The user's .GNUsteprc file is included after the
> system one, so a user should be able to override GNUSTEP_USER_ROOT 
> with
> whatever they want.

... please think about the inherent "system" user (root) as well.  
There's just something about writing into /root that's just .... 
wrong, imho.  This is in the context of "daemons" and such ... if 
someone's running GNUMail as root, well, sure they get a ~/GNUstep 
(and a punch in the face!) (j/k) (...or I am?)

> If you are running a tool for a user with no directory but you still 
> want
> defaults to be written somewhere, you could pass on the command line 
> the
> argument to specify a special user .GNUsteprc, gnustep-base would read
> that, and use it to locate the defaults on the filesystem wherever you
> want to put them.

Yes.  Hoping as an env var before the command (bash style), but 
whatever works.

> make_services would no longer be necessarily run automatically, since 
> you
> no longer source GNUstep.sh.  It shouldn't be there in GNUstep.sh 
> anyway,
> but we have to decide where/if it should be.

.bashrc / .bash_profile (or similar for other shells) (whichever is 
always read at "login").

> It would be good to limit the usage of gnustep tools in makefiles; 
> except
> where explicitly required (you can't build autogsdoc documentation 
> without
> running autogsdoc) we shouldn't be running any gnustep tool.  If a 
> tool is
> required by the makefiles, it should be a C tool included with
> gnustep-make.

YES! YES! YES! :-)  ... except that autogsdoc shouldn't try to write / 
create Defaults either (couldn't pin down if it also was a culprit of 
my frustration, but I believe it was).


> Thanks to all

No, thank you. :-)

__armando