[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUstep-packagers] patch for observance of $HOME
From: |
Richard Frith-Macdonald |
Subject: |
Re: [GNUstep-packagers] patch for observance of $HOME |
Date: |
Sun, 8 Aug 2004 10:24:49 +0100 |
On 8 Aug 2004, at 06:22, Sheldon Gill wrote:
I thought it best to modify the format somewhat. I posted some
examples a
while ago along with a discussion about how it works.
Basically, it makes the file a little easier to understand and allows
configuring additional things.
Rather than have the FORCE_ flag to prevent per user configs, you
instead
specify the USER_GNUSTEP_RC to be the empty string (ie. source no file)
It means the file ends up like this:
----<GNUstep.conf>----
# System paths
GNUSTEP_SYSTEM_ROOT = /usr/local/GNUstep/System
GNUSTEP_NETWORK_ROOT = /usr/local/GNUstep/Network
GNUSTEP_LOCAL_ROOT = /usr/local/GNUstep/
# GNUstep preferences
USER_GNUSTEP_DIR = GNUstep
USER_GNUSTEP_DEFAULTS = Defaults
USER_GNUSTEP_RC = .GNUsteprc
----<end>----
Nice and simple but providing all the flexibility required.
Looks reasonable to me. I like the idea of specifying the name of the
rc file. The only problem
with this is that I *think* we had someone who needed to support a
group of users who had a
single shared read-only default system but separate user directories
(which is why there are
separate 'FORCE' options for the directory and the defaults). That's a
rather esoteric
requirement though, and I'm not sure I'm remembering correctly.
Perhaps they could have
got the effect they wanted by using an absolute path for the defaults
file and disabling the
user specific rc file.
You don't say what is relative to what in cases where an absolute path
is not given.
In the current code the GNUSTEP_DEFAULTS_ROOT and GNUSTEP_USER_ROOT are
absolute or have a '~' prefix to denote a path relative to the users
home directory. I guess
omitting the '~' and just saying that relative paths are based on the
home directory might
be better.
However, if we are rationalising this stuff, I think the naming should
be consistent ... either
we should put 'GNUSTEP' at the start of each name or, omit it
altogether. Also, we should
use ROOT rather than DIR for consistency between the user domain and
the other
domains...
SYSTEM_ROOT=/usr/local/GNUstep/System
# must be absolute. if omitted, assumed to be the directory containing
the top level rc file
NETWORK_ROOT=/usr/local/GNUstep/Network
# must be absolute. if omitted, assumed to be same as SYSTEM_ROOT
LOCAL_ROOT=/usr/local/GNUstep/Local
# must be absolute. if omitted, assumed to be same as SYSTEM_ROOT
USER_ROOT=GNUstep
# absolute or relative to home directory. if omitted we use home
directory
USER_DEFAULTS=GNUstep/Defaults
# absolute or relative to home directory. if omitted we use home
directory
USER_RC=GNUstep/.GNUsteprc
# absolute or relative to home directory. if omitted no user specific
config
If I remember correctly, you once provided a huge change in one go,
then split
it up into pieces which all had to be applied in order to work. For
people to be
happy with an alteration a more gradual approach is needed, where each
part can be applied and tested in its own right. Also we should try to
keep
separate things which are bugfixes and things which are changes ...
bugfixes
are non-controversial and can be easily applied, changes to behaviors
(most of what we have been talking about here) need debate. It's not a
good idea to mix the two in one patch as it will just stop the fixes
being
applied.
If we actually want to make such changes, I think we need to do it in
stages ....
1. change the make and base packages to look for a config file in a
default
location and if it is not present, to look in an environment variable
for its
location.
1a. at the same time, clearly document the rules for locating this
config file.
1b. If the file does not exist, what do we do?
I think we should probably print a comprehensive error message and bomb
out.
The alternative is to proceed on the assumption that GNUstep is
installed in the
directory in which we expected to find the rc file (either the
directory given by
the GNUSTEP_ROOT environment variable, or the one defined at
build/configuration
time), but I think insisting on the presence of the rc file is 'safer'.
However, if we do
this we have to install a default config file (where necessary) in
order to avoid
breaking peoples existing setups when they upgrade.
1c. If the file exists but is not readable (or if any directory in the
path to it exists
but is not accessible), what do we do?
I think we assume that the system manager has reprotected the file in
order
to temporarily disable all applications ... so we should write an error
message
explaining exactly why we couldn't read the config, and again we exit.
1d. If the file is writable by anyone other than its owner or any
directory in its
path is writable by anyone other than its owner, we probably want to
bomb
out as it may have been tampered with.
While this change involves quite a lot of work, it's pretty localised
since it deals
only with locating the configuration file ... so we can do it and test
that it doesn't
break anything and inspect the code to be clear on what it's doing.
2. Change the parsing of the config files to the new values/rules
2a. Fully document the new values.
2b. Possibly retain the code to parse the old format, and print warning
messages
if any old format config files are found ... this to be phased out in a
later release.
2c. Check per-user config files for security like we did with the
system config file.
Again, this file parsing is localised stuff and the security checking
can use the
same routine used to check the security of the top-level config file
... if that
routine was carefully written in the first place. So checking this
modification
should be fairly simple.
3. Put together convenience scripts/utilities to set up the unix
environment to
run GNUstep programs.
Fairly simple and localised changes ...
4. Any other fixes in path utilities etc should be possible to do as
small localised
bugfixes which are easily checked and tested by people.
5. In a later version, remove any old code retained for backward
compatibility.
- Re: [GNUstep-packagers] patch for observance of $HOME, (continued)
- Re: [GNUstep-packagers] patch for observance of $HOME, Armando Di Cianno, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio M . Serrano Jr ., 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio Serrano, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/08
- Re: [GNUstep-packagers] patch for observance of $HOME,
Richard Frith-Macdonald <=
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/10
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio M . Serrano Jr ., 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Armando Di Cianno, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio M . Serrano Jr ., 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/07
Re: [GNUstep-packagers] patch for observance of $HOME, Armando Di Cianno, 2004/08/06