discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GNUstep.sh / env sanity patches


From: Richard Frith-Macdonald
Subject: Re: GNUstep.sh / env sanity patches
Date: Tue, 17 Aug 2004 20:28:00 +0100


On 17 Aug 2004, at 20:10, Armando Di Cianno wrote:

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.

gdomap definitely doesn't.

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!

Running gnustep applications as root will use root defaults ... I think that's as it should be! However, I feel you ought to be able to configure where you want this to be in GNUsteprc. Similarly, daemons should not run as root, but it should be possible to redefine where they store defaults if you want to. Personally, I'd prefer to keep them in the appropriate home directories, but you should be able to do something different if you want to.


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.

Well, running openapp is equivalent to sourcing a script ... with the work done within openapp. My preference is to source a script once when I log in, so I don't need to use openapp, but either works.

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.

I think that sort of thing needs to be fixed in the individual files concerned. A patch to do that should be easy to check and incorporate as it won't effect anything else.

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.

I guess, to keep people happy, we may have to make the 'standard' location of the top level GNUsteprc configurable at build time. I have no particular preference about where it should be ... I'm happy with the current /usr/GNUstep location, but I seem to recall that others writing to this list are not.

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 ;-)]

Again, this sounds like an uncontroversial case where a patch could be easy to check and apply without risking breaking anything.

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.

Yes, once LD_LIBRARY_PATH is set make_services should be able to run.

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?)

Normally /root is roots home directory ... I think files belonging personally to root (as a user) *should* be put there. The stuff that shouldn't be put there is stuff that is expected to be shared by many users of the machine. While you can argue that root shouldn't be running GNUstep applications, I think this is the correct place for their files if they do. However, I think that GNUsteprc should be able to override the location for indivdual cases like root if you want to set it up that way,





reply via email to

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