Re: [GNUstep-packagers] patch for observance of $HOME

[Richard Frith-Macdonald]

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.