|
| From: | Armando Di Cianno |
| Subject: | Re: [GNUstep-packagers] patch for observance of $HOME |
| Date: | Fri, 06 Aug 2004 10:26:42 -0400 |
I'm not sure I follow this ...My understanding is that we already have no hard coding of paths except for a few backup cases for if the environment variables are not set up. Are you simply saying that these last-resort backups should be removed, so that apps will just bomb out if they are not given basic path information at runtime (when they start) ? If so, I'm not averse to that idea as long as we can make sure that, when a program can't run for lack of path info, it can give clear and simple instructions on how to provide it with the information it needs.
The latest incarnation of my quest to resolve my issues, has me convinced that if across the board "where to write defaults?" issue is addressed the ideal process for discovering paths would go like this:
0) env vars - "Did the user configure the instance of this app?"1) static files - "Did the system maintainer configure the default behavior of this app?" (.GNUsteprc does this to some extent) 2) "happy defaults" - "App says, `I'm alone and frightened, what do I do?`"
As far as the environment v file issue goes ...Environment variables are fast, but I've seen complaints in the past about GNUstep cluttering the environment with too many variables. The issue abut environment variables getting removed when su and similar utilities are run is also a problem.
GNUstep should be able to drop a big portion of it's env vars that get set in GNUstep.sh currently. If prefix is set to /usr/GNUstep, then it should be assumed that System, Local, Network are in there ... 'cept if an env var is set, then use the env var, imho. The "su" issue is sort of a pet peeve for me. I think I spent something like a full year frustrated that su seemed to mangle root's environment ... but then I realized: when one uses "su" one is "asking for system permissions" ... this is terribly different than "su -" when one wants to "become root". If one wants a GNUstep environment to run programs as root (WHY?!), then one should use "su -".
The .GNUsteprc config file is slower, but we can avoid most of the environment clutter ... however, we still need something like an environment variable to specify the system root so we can find the config file. We also need to modify PATH and LD_LIBRARY_PATH etc to allow GNUstep programs to be simply run from the unix shell.
I'm going to release a ~x86 ("testing" in Gentoo-speak) set of GNUstep packages this weekend finally ... and the solution I found, at least temporarily, is going to get me years and years in developer purgatory. Basically, if I don't allow userpriv's (this is bad, 'cause it hacks around something useful) in emerge (normal emerge runs as root, but one can drop it down to user priv level), and gnustep-make installs a .GNUsteprc with only "GNUSTEP_USER_ROOT=/var/tmp/portage/homedir/GNUstep" set, and _force_ users to set their own .GNUsteprc with "GNUSTEP_USER_ROOT=~/GNUstep" then I can mostly get this to work w/o large changes. But this is just for installing. There's others cases where changing (what amounts to $HOME / $GNUSTEP_USER_ROOT) is helpful. _I_ don't care, but some may not want a GNUstep directory for defaults in /root everytime gdomap is executed. "But why don't you just set the system .GNUsteprc?" Well, right ... but I basically need to to be dynamic ... kind of like an env var. :-\
I don't like the idea of using the HOME environment variable ... as it is not reliably present/correct.
Absolutely. I have had a hard time making it clear previously, but simply I wanted to observe it if it was there.
The $GNUSTEP_ROOT/.GNUsteprc file already allows the home directory of a user to be controlled, and I would have thought that this was sufficient to solve Armando's problems with Gentoo. eg. where he would like to set HOME=/xxx/yyy he could set GNUSTEP_ROOT=/xxx/yyy and create a .GNUsteprc file in that directory containing 'GNUSTEP_USER_ROOT=/xxx/yyy' to run everything within that directory.
(see above) ... it _almost_ is enough. If you can think of another creative way to use it, pleae let me know though ... heh, I'm trying to be somewhat "low impact". :-) [edit: oh wait, i'm re-reading this suggestion, and I'm going to have to try that -- that is pretty creative. In the end, it's still slightly muddy with hackery, but, whatever -- that's some good hackery. :-) ]
For GNUstep's future (well, "future-growth"), maybe we should make a plan for attacking these issues. I gave my "where to get settings" suggestion above, as well as Richard's in this email I'm responding too, but maybe we should also really take a look and audit not just GNUstep.sh (make_services called, autogsdoc called for docs), but all the tools (user_home), the libraries for App's (NSUser.m), and the roles the specific tools take (gdomap, etc), and what the should be calling $HOME. I do love choice and configurability, but I think the many ways to configure the GNUstep env in subtle ways is, well, a bother to me, but potentially a bother to all users.
__armando
| [Prev in Thread] | Current Thread | [Next in Thread] |