Hrm, not one response.
... I guess that mean everyone just LOVES these patches, eh? ;-)
I realize the entire GNUstep.sh related issue is quite sensitive for
people, but these patches don't/shouldn't alter current behavior.
Sorry, I was on holidays.
The discussion is getting interesting, it's probably time to do
we've got plenty of patches pending, even if I'd like to start again
Shall we recap a little bit the state of the issue. :-)
We've inherited a system which was designed many years ago to support
* support multiple concurrent separate installations at the same time,
and where switching from one to the other was very simple
* support multiple runtimes, base, gui libraries, and where switching
one the other was very simple
* support multiple architectures with a fat layout
* support multiple types of libraries (debug, profile, etc) with
linking to the right one
* support dropping applications, tools, libraries, frameworks into
user's "domain" and have them immediately work without any
* have a *Step filesystem layout and organization separated from the
of the system ("better" than the rest of the system)
Now we have new design requirements (which were not given particular
importance in the original design), and which are generally
with the previous ones. I mean, people would like a system which --
* is a native system which follows the native filesystem organization
* works out of the box, natively, without requiring any setup (no
Those people generally also don't need/use many of the "support
xxx" features, often they think those are confusing problems rather
An additional requirement which often pops up is that the system
* allow each user to put one's user domain and user defaults in the
directory / location that they want.
Presumably the solution that we're going to architect will be flexible
enough to support both styles. That might be quite a complex
Now there are some additional things to notice.
1. To support libraries and frameworks in the user domain,
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
that if you source no startup scripts, you won't be able to put
and frameworks in the user domain. To be able to do so, you'll still
to source a script.
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.
Anyway, it looks like a reasonable architecture could be --
We have a system GNUsteprc file. The format of the file should be
that 1. it can be easily parsed by gnustep-base; 2. it can be
shell scripts and makefiles (including is the only real solution for
makefiles to get decent parsing speed). A text format with XXX=YYY
where XXX is some variable/name we choose, and YYY is what we want to
it to (normally a path, but might be YES/NO too or something similar),
seems best. It does fulfill those requirements.
The GNUsteprc is expected to be on a specific location which depends
the platform (for example, /etc/GNUsteprc in linux). Presumably the
hardcoded location of the file can be changed at config time.
This works very well for a single GNUstep installation on the
machine. If we
want to support multiple installations though (even if as a special
case where you need to source scripts to do it) there must be a way to
override the file with another one -- to tell gnustep-base to use
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
Then if you want to have multiple installations, you can have them in
different locations. You run scripts to change 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
to the crazy people who do those things with multiple installations
I do, even if only for testing); for a single GNUstep installation
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
shell variable needs to be set, nothing.
Unfortunately, tricky bits abund. The GNUsteprc file will implicitly
specify, for example, where gnustep-base should look for basic files
as character sets (if gnustep-base is installed in /usr/lib/ and the
character sets are installed in a totally different unix location
used for library resources, locating them can be non trivial as the
location might be totally unrelated to gnustep-base's shared object
location). Now if you have a suid tool compiled using gnustep-base,
don't want the user running the tool to be able to tell gnustep-base
load those files from another location other than the standard one,
otherwise they could load their own malicious stuff and have
running as root use it -- a potential attacking technique.
So maybe what we could do is that "delicate" tools could tell
not to accept the special command line argument / shell variable to
the GNUsteprc file to be read. A function call performed just after
main() would tell gnustep-base to run in "howitzer" mode where it
requests to read GNUsteprc files other than the default /etc system
if you're writing a "delicate" system script (eg, anything suid), you
call that function and you're safe from those attacks.
If the GNUsteprc file is missing, gnustep-base would abort. When
gnustep-make is installed, GNUsteprc would be installed as part of
gnustep-make, so this should never happen unless you're doing weird
The GNUsteprc file would contain stuff like --
(the reason we still prefix those with GNUSTEP_ is that the file
included in makefiles and shell scripts, where we want to stay in our
namespace). I suppose any of those is optional but
which is compulsory.
We'll also add optional stuff like
(better names to be determined of course) etc. Those needs to be
discussed, but the list should be quite easily produced by looking at
variables the makefiles use and what dirs are available in the
API. Presumably GNUSTEP_SYSTEM_ROOT would not be much use if all
are manually set to something else.
Would you be able to override those using shell variables ? No.
no reason why you should be able to. If you want to change those,
a different GNUsteprc script and point gnustep-base to it.
Of course if you're using makefiles and shell scripts it might still
if you manually override those before using them, but that's not
to be supported (/work).
Now if you add manually your tools/library paths to PATH / ld.so.conf
that should be it. You don't need to do anything else. Even better,
you are setting GNUSTEP_SYSTEM_LIBRARY_DIR and similar to the native
system paths, this might not be needed at all. Everything should just
If you want to have the same functionality that we have at the
would make a tradional *Steppish installation of GNUstep in its own
separate filesystem, then you'd source GNUstep.sh. GNUstep.sh would
actually no longer contain hardcoded paths, but would include
/etc/GNUsteprc (optionally I suppose GNUstep.sh could accept a
file location as an argument) to get the paths, then use those to set
paths, library paths, classpaths, etc. When the time comes it will
pleasure to rewrite all that shell/makefile machinery to do this, so
worry too much about this -- as soon as the format is such that the
can easily be included, we'll have shell/makefile machinery use it.
You might still need to source GNUstep.sh -- for example if you want
install libraries / frameworks in your own user domain, even if you
not interested in multiple installations. I do like that.
The final issue is how users can customize the location of their user
domain path / user defaults database (important, as usual,
when running as the superuser should be able to determine the
the user defaults of another user as that's required to implement the
which lets the superuser touch defaults of other users).
Each user could have his own GNUsteprc, which would need to be the
~/.GNUsteprc. Of course again a system of command line switches /
variables could allow users to change this to another file; again suid
tools (or just "delicate" tools) could be compiled to ignore requests
read another file.
The ~/.GNUsteprc file should contain only the location of
GNUSTEP_USER_ROOT and of the GNUSTEP_DEFAULTS. gnustep-base can
anything else in the file; shell scripts and makefiles will just
include the whole file, meaning the user could set a different
GNUSTEP_SYSTEM_ROOT in it but that's the user's problem, things just
work, it's not a security risk, we have no suid shell scripts or such.
Probably if the sysadmin wants to recommend a standard location for
user domain path / user defaults database, the system GNUsteprc could
contain something like
Presumably if that's included in a shell script or in a makefile it
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
whatever they want.
The current option to be able to FORCE some choice of USER_ROOT or
DEFAULTS_ROOT for all users would be dropped. I don't believe it has
real use, if there is something we have to drop to square the circle
make the system flexible but reasonably understandable, the FORCE
are the best candidates.
If you are running a tool for a user with no directory but you still
defaults to be written somewhere, you could pass on the command line
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.
make_services would no longer be necessarily run automatically, since
no longer source GNUstep.sh. It shouldn't be there in GNUstep.sh
but we have to decide where/if it should be.
It would be good to limit the usage of gnustep tools in makefiles;
where explicitly required (you can't build autogsdoc documentation
running autogsdoc) we shouldn't be running any gnustep tool. If a
required by the makefiles, it should be a C tool included with
gnustep-make. I don't think that should be a problem except for
make_services itself, which is only run in test mode anyway, hmmm,
probably that should be replaced with some sort of shell check, hmmm
This is all an initial draft generated by mixing up comments,
ideas, patches from a lot of people, so feel free to comment on it --
we'll let people discuss quite a bit before taking any actual
but I'd really like to implement it in the next few weeks. Anything I
missed in this description (there is always that last difficult
detail) ? Special comments ?
Please excuse me if I'll not answer quickly or if I stay out of long
threads -- keep banging and suggesting anyway
Thanks to all