[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 <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
- Re: GNUstep.sh / env sanity patches, (continued)
- Message not available
- Re: GNUstep.sh / env sanity patches, MJ Ray, 2004/08/16
- Re: GNUstep.sh / env sanity patches, Alexey I. Froloff, 2004/08/13
- Message not available
- Re: GNUstep.sh / env sanity patches, MJ Ray, 2004/08/13
- Re: GNUstep.sh / env sanity patches, Alexey I. Froloff, 2004/08/14
- Re: GNUstep.sh / env sanity patches, Pete French, 2004/08/14
Re: GNUstep.sh / env sanity patches, Nicola Pero, 2004/08/17
Re: GNUstep.sh / env sanity patches,
Armando Di Cianno <=
Re: GNUstep.sh / env sanity patches, Richard Frith-Macdonald, 2004/08/17
Re: GNUstep.sh / env sanity patches, Nicola Pero, 2004/08/17
GNUsteprc location (was: Re: GNUstep.sh / env sanity patches), Dennis Leeuw, 2004/08/18
Re: GNUsteprc location (was: Re: GNUstep.sh / env sanity patches), Nicola Pero, 2004/08/18
Re: Re: GNUstep.sh / env sanity patches, jhclouse, 2004/08/12
Re: GNUstep.sh / env sanity patches, John Davidorff Pell, 2004/08/17