[Top][All Lists]

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

Re: NSUser and paths generally

From: David Ayers
Subject: Re: NSUser and paths generally
Date: Tue, 16 Dec 2003 19:25:20 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007

Sheldon Gill wrote:

It seems that NSUser.m was originally created by Andrew McCallum for a new class that handled login related functions.

However, it mainly contains the functions from "NSPathUtilities.h". I propose moving those functions to a new file "NSPathUtilities.m" where they would seem more at home.

Hello Sheldon,

<disclaimer> I don't consider myself a -base maintainer. </disclaimer>

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 also propose making some modifications to the path handling routines:
* Initialise the various root directories from a plist in /etc/GNUstep if it exists, over-riding environment variables. This will allow system administrators to enforce system file heirarchy policy.
It'll also mean that, on such systems, you don't need to source!
* Add support for traditional locations for applications and libraries:
   NSApplicationDirectory   /bin /usr/bin
   GSLibrariesDirectory      /lib  /usr/lib
   NSAdminApplications    /sbin /usr/bin
These will be last in the returned array.
* Extend support for more parts of the heirarchy like:
   Fonts, Palattes, ColorPanels, Services, etc

What I wish to work towards is making GNUstep highly path layout agnostic and consolidate it's file dependancies.

This will ease packaging GNUstep for different platforms. I'm particularly thinking of Win32 but Debian will also benefit quite immediately. Other things to be done along these lines is extending the defaults system to allow for installation defaults. This would allow a system administrator to set up an environment for all users quite easily.
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).

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

I the available ./configure options of -make together with (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:
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.)


reply via email to

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