Re: Totally Gormless

[Armando Di Cianno]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005-10-12 09:44:52 -0400 Nicola Pero
<nicola.pero@operatelecom.com> wrote:
> But ... when I looked at the names and started to think how to 
> integrate
> with gnustep-make my hair went straight up ;-)
<snip>
> Btw, how did we choose the names 'SYS' / 'PLATFORM' / 'PLATFORM_LOCAL'
> btw?  It looks like the 'SYS' is missing the resource directory, 
> which is
> essential to us (isn't it ?  bundles / apps / frameworks will go in
> there).  Also, 'SYS' seems to map to where usually the core Unix 
> stuff is
> installed -- and where we won't install anything! Presumably we 
> actually
> want to have SYSTEM --> /usr/, LOCAL --> /usr/local/, and leave / 
> alone ? 
> Except for maybe /etc/GNUstep that would map to some GNUstep system
> preferences directory ?
<snip>
> Any special comments ? (please no flamewars though, be polite thanks)

Actually, I filed a bug about something unrelated, the ended up being
a "documentation" bug.  There were *a lot* of changes in 0.11.0
release (and .1).  However, if you look at
file:///$GNUSTEP_SYSTEM_ROOT/Library/Documentation/Developer/Base/Reference/index.html
, under "GNUstep Configuration File"  you'll find the explanation for
those entries.  They have nothing to do with the GNUstep layout --
rather, they have to do with the UNIX/system layout that GNUstep is
being installed upon.  For e.g:
"SYS_APPS
     Place for system/os applications (eg. '/bin')"
... so no worries there. :-)

> > However, I think it was about last year this time when I submitted 
> > similar 
> > patches against an older -base, and they were rejected, iirc, 
> > because some 
> > were afraid of what would happen if someone used "su" ...
>
> That might actually be a good argument. :-(
>
> (I haven't looked at the patches though)

FWIW, this is a *terrible* argument.  Using "su" (without -) will
break things -- it'd do this for GNUstep, it does this for other
things.  If people want to "switch permissions" *and* have a sensible
environment, *they have to* use either sudo or "su -".  Have to.
Period. :-)

> > Another reason for the patch is that I also need it for allowing 
> > builds to 
> > complete while in a sandbox (i.e. Gentoo ebuilds).  The simple act 
> > of 
> > making or installing apps, and docs, would create ~/GNUstep in /root.
>
> Thanks - this is certainly an interesting problem :-)
>
> I would have imagined the new configuration system would give you 
> enough
> power to redirect the root's user directory / defaults to /tmp/xxx 
> ... ;-)
>
> .... maybe not ?

No -- this is the root of the problem.  user_home is broken, so it is
giving the wrong answer anyways, but NSPathUtilities.m uses getent()
- -- which is good/great for almost all intents and purposes -- based 
on
the user name of the user on the system.  Eventually, when the "home"
is calculated, it only uses the value from getent -- so there is *no
way* to override this in a "one time" fashion.  It is/was possible to
override the GNUstep dir / Defaults dir for a user based on GNUsteprc,
but this is not possible when you either a) are installing
gnustep-make and have no other GNUstep related files already on your
system or b) you are against putting a file into /root just so /root
won't have a directory created.  And to do this (in the old GNUsteprc
way), you'd have to allow user override anyway, which was/is
problematic for that system.  Either GNUSTEP_USER_DIR needs to win, or
$HOME needs to be respected.  Because of the conf file code "ripple
effect" of how it decides what directories are what, GNUSTEP_USER_DIR
is almost always (always, actually, iirc) overriden.

In my experience, order of precedence for "conf variables" should be:
0) environment variable
1) user rc file
2) system conf file
env vars should always taken precedence; however, a high layer (set by
the sys admin, maybe) could say "no override" and then it wouldn't;
either way, this defacto rule is the case everywhere else, and I
believe it should be adhered to.  "The Art of Unix Programming" says
so even. ;-P

__Armando Di Cianno

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1-ecc0.1.6 (GNU/Linux)
Comment: Using the GPG bundle for GNUMail

iD8DBQFDTSG5wgiTPLI9xhcRAoSbAJ9x9gbMAszzKpqCS3WKAjZtWUgFTgCfSKgO
m4P5EJfzsxZuwqZRsQD52uY=
=gDAe
-----END PGP SIGNATURE-----