gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSUser and paths generally


From: Sheldon Gill
Subject: Re: NSUser and paths generally
Date: Wed, 17 Dec 2003 10:19:40 +0800
User-agent: KMail/1.5.93

On Wed, 17 Dec 2003 02:25, David Ayers wrote:
> NSUser.m contains functions associated with the user and his environment
> defined in NSPathUtilities.h.  There is no such thing an NSUser class.
> You are effectively proposing to rename NSUser.m to NSPathUtilities.m.
> I'd think thrice before dealing with the issues realted to obtaining the
> CVS history for these file just for the functions to be "more at home".
> (OTOH, I was the one who moved all the header files a while back :-) )

I was thinking of leaving the user name and such login functions in NSUser and 
moving the path discovery to NSPathUtilities. The correspondence between 
header and source makes life a little easier but that's not the sole reason 
for the change.

Currently, there are file system dependancies/assumptions in many different 
places throughout the code. My aim is to consolidate them as far as possible 
and 'clean' things up somewhat. This will pave the way for behaviour 
improvements.

> I guess some administrators may not want users to be able to change the
> behavior of their apps by tweaking environment variables, yet
> introducing new static search locations like /etc/GNUstep doesn't add to
> GNUstep's portability (even if it's ignored when it diesn't exist, we'd
> still need an analogous mechanism for other platforms like MinGW other
> distros that don't have /etc).

The right answer for Win32 is HKLM\Software\GNU\GNUstep\ with string keys 
equal to the environment variables.
/etc/profile is _not_ a packaging option here. Requiring a bourne-shell 
compatible program installed and run on start-up isn't very friendly either.

I made this suggestion in relation to 'packaging' rather than 'portability'. 
Implementing this would mean that GNUstep system configuration for most *nix 
would be in /etc/GNUstep which is consistent with what other packages do, 
especially WindowMaker. Make life easier for sys admins.

It would also mean you could run GNUstep applications without sourcing 
GNUstep.sh. Plus, you lose the -make dependancy. I see win, win here. Break 
nothing and add important functionality.

> Yet how would you stop a user from using LD_LIBRARY_PATH & co. to
> manipulate behavior?

LD_ & co are concerns for administration and security more generally. There 
are various approaches to this problem which is really beyond the scope of 
this discussion. (and, I feel, of gnustep itself)
Providing an alternative behaviour opens the door for such pursuits.

> I the available ./configure options of -make together with GNUstep.sh
> (sourced by /etc/profile) should give you some freedom to setup a custom
> the environment.  Yet this does not include putting apps and libraries
> in to places not defined by:
> http://www.gnustep.org/resources/documentation/filesystem.ps

This _requires_ having -make installed. It also means problematic behaviour 
with su.

I'm not advocating putting GNUstep applications or libraries in places not 
defined by GFSH. Adding these paths to the search path return means 
applications can find things in /lib or /bin using the same mechanism as 
everything else.

Consider this:

My application can support LDAP but doesn't require it. Such support is built 
on OpenLDAP. How do I know that the platform I'm on supports it? Without a 
registration mechanism the only reliable way I can think of is to search for 
libopenldap.so.1 in the library path.

> Please also refer to the archives (of -discuss I believe) for past
> discussions on the topic.
>
> I don't want to block new discussion about the filesystem but this is a
> contraversial subject and possibly more apropriate in -discuss (at least
> until the positions are clairified.)

I remember Tim's GSFH thread and other more inflammatory ones. My aim isn't to 
re-ignite such debate. The "preferred" GNUstep layout is in the GFSH 
document. I'd address changes to that separately. {which I intend to do to 
clarify/document NSDeveloperDirectory behaviour}


Regards,
Sheldon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]