[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep.sh / env sanity patches

From: Armando Di Cianno
Subject: Re: GNUstep.sh / env sanity patches
Date: Tue, 17 Aug 2004 15:10:08 -0400

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 <address@hidden> 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 --


(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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]