The discussion is getting interesting, it's probably time to do
something,
we've got plenty of patches pending, even if I'd like to start again
from
scratch.
Shall we recap a little bit the state of the issue. :-)
We've inherited a system which was designed many years ago to support
the
following --
* 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
from one the other was very simple
* support multiple architectures with a fat layout
* support multiple types of libraries (debug, profile, etc) with
automatic linking to the right one
* support dropping applications, tools, libraries, frameworks into
each
user's "domain" and have them immediately work without any
reconfiguration
* have a *Step filesystem layout and organization separated from the
rest
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 conflicting
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
startup
scripts etc)
Those people generally also don't need/use many of the "support
multiple
xxx" features, often they think those are confusing problems rather
than
features.
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.
Presumably the solution that we're going to architect will be flexible
enough to support both styles. That might be quite a complex solution
though.
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.
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 such
that 1. it can be easily parsed by gnustep-base; 2. it can be included
in
shell scripts and makefiles (including is the only real solution for
makefiles to get decent parsing speed). A text format with XXX=YYY
lines,
where XXX is some variable/name we choose, and YYY is what we want to
set
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 on
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
another
file.
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,
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.
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
character sets are installed in a totally different unix location
which is
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,
you
don't want the user running the tool to be able to tell gnustep-base to
load those files from another location other than the standard one,
otherwise they could load their own malicious stuff and have
gnustep-base
running as root use it -- a potential attacking technique.
So maybe what we could do is that "delicate" tools could tell
gnustep-base
not to accept the special command line argument / shell variable to
change
the GNUsteprc file to be read. A function call performed just after
main() would tell gnustep-base to run in "howitzer" mode where it
ignores
requests to read GNUsteprc files other than the default /etc system
one.
So 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
things.
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.
We'll also add optional stuff like
GNUSTEP_SYSTEM_LIBRARY_DIR=/usr/lib
GNUSTEP_LOCAL_LIBRARY_DIR=/usr/local/lib
(better names to be determined of course) etc. Those needs to be
discussed, but the list should be quite easily produced by looking at
what
variables the makefiles use and what dirs are available in the
*steppish
API. Presumably GNUSTEP_SYSTEM_ROOT would not be much use if all those
are manually set to something else.
Would you be able to override those using shell variables ? No.
There is
no reason why you should be able to. If you want to change those, you
use
a different GNUsteprc script and point gnustep-base to it.
Of course if you're using makefiles and shell scripts it might still
work
if you manually override those before using them, but that's not
supposed
to be supported (/work).
Now if you add manually your tools/library paths to PATH / ld.so.conf
then
that should be it. You don't need to do anything else. Even better,
if
you are setting GNUSTEP_SYSTEM_LIBRARY_DIR and similar to the native
system paths, this might not be needed at all. Everything should just
work.
If you want to have the same functionality that we have at the moment,
you
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
GNUsteprc
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 be
my
pleasure to rewrite all that shell/makefile machinery to do this, so
don't
worry too much about this -- as soon as the format is such that the
file
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 to
install libraries / frameworks in your own user domain, even if you are
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, gnustep-base
when running as the superuser should be able to determine the location
of
the user defaults of another user as that's required to implement the
API
which lets the superuser touch defaults of other users).
Each user could have his own GNUsteprc, which would need to be the file
~/.GNUsteprc. Of course again a system of command line switches /
shell
variables could allow users to change this to another file; again suid
tools (or just "delicate" tools) could be compiled to ignore requests
to
read another file.
The ~/.GNUsteprc file should contain only the location of
GNUSTEP_USER_ROOT and of the GNUSTEP_DEFAULTS. gnustep-base can ignore
anything else in the file; shell scripts and makefiles will just
stupidly
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
won't
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 the
user domain path / user defaults database, the system GNUsteprc could
contain something like
GNUSTEP_USER_ROOT=~/GNUstep
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.
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
any
real use, if there is something we have to drop to square the circle
and
make the system flexible but reasonably understandable, the FORCE
options
are the best candidates.
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.
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.
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. 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
stuff
todo.
This is all an initial draft generated by mixing up comments,
suggestions,
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 decision
--
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 missing
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
smime.p7s