Re: GNUstep directory layout

[Tim Harrison]

Dennis Leeuw wrote:

> * I would change DocTemplates to DocumentTemplates to be consistent with
> all other directory names which are spelled out (that entire directory
> should imho go into the Documetation directory since they are documents).

I would agree with using full words for directory names. 
DocumentTemplates would definitely be preferable.  However, I must 
respectfully disagree with moving Doc[ument]Templates into a 
Documentation directory.  Documentation is where, well, documentation 
lives.  If there were to be many more types of templates, then maybe a 
$DOMAIN/Library/Templates directory should exist.

> * Users doesn't belong in Network by default. By default Users are local to
> a system, so they should belong in the Local domain.

Unless they're not local to a system.  In some of the environments I 
work in, users are NOT specific to a local machine, except for root, and 
an administrative user.  The rest are held in a directory service, and 
home directories are mounted from either a departmental server, or a 
central fileserver.  These users should not be mounted in /Users, or 
/Local/Users, because, well, they're not local users.  They're network 
users ("/Network/Users").  Or, in one case, they're users on multiple 
servers on the network ("/Network/Servers/<servername>/Users").  Yes, I 
could see the benefit of having <servername> in /Network, but it could 
also confuse the structure within /Network.  However, point being, on 
these machines, I want only root and the administrative user to have 
home directories on the local machine itself, for situations when 
something needs to be managed on the local machine, and the NFS mounts 
are either not there, or not responding.

> * The same goes for Servers, and imho is there a big difference between
> Servers and Tools? Is the destinction between CLI and Graphical not enough?
> Do gpbs, gdnc and gdomap then become part of Servers?

To me, gpbs is a server.  gopen is a tool.  Neither are graphical. 
However, in OpenStep/GNUstep(/Mac OS X?), tool seems to be specific only 
to non-GUI programs.  Tough call.

> But I think the most important thing I missed is the definition of the
> domains. Without a clear description of what a domain means, one can argue
> for ages. The above is based on my assumption that:

Check out the full proposal that Martin Brecher and I put together this 
past April.  Martin wrote excellent descriptions of the domains.

http://www.linuxstep.org/documentation/GNUstepFH.html

> User Domain: Everything installed by a specific user in his/her own home
> directory, which actually should be /Local/Users/<user-name> (on a Un*x
> system is could be a symlink to /home).

Symlink, sure.  But user home directories should not be 
GNUstep-specific.  I'm not going to move my home directories into 
/Local/Users, unless /Local is expected to be 100% always on my machine. 
 Even then, I prefer to have my users closer to my root directory, with 
less levels of structure above them.  Most GNUstep users don't fully 
integrate their GNUstep installations with their system (ie. quite a lot 
install into /usr/GNUstep, or /opt/GNUstep), so only a symlink *from* 
/home (or /Users) should be considered.  But, now we have multiple ways 
of referencing the home directory.  One part of the system could 
reference it one way, another might reference it a different way.  Are 
you going to go through and change your installed users' home 
directories in the password file to /Local/Users/username from 
/home/username?  What if your GNUstep is installed in /opt/GNUstep? 
Would you then change your users from /home/username to 
/opt/GNUstep/Local/Users/username?

> This is how I view the system. And that restricts me in my choices for a
> directory layout.
> Comments welcome. Flame wars are useless... ;)

I don't flame, but sometimes wars start from the things I say. :/  I 
must be controversial by nature. :)

For an example of how GNUstep integrates into a specifically designed 
system, have a gander at the LinuxSTEP Filesystem Hierarchy document 
(http://developer.linuxstep.org/downloads).  The LSFH is a combination 
of our original GNUstep proposal and our own structures.  I'll be 
posting a new version of this document soon, with some much-needed 
modifications (the /System/ApplicationData structure needs some serious 
attention).  This is what the new version of LinuxSTEP (working on it) 
will look like.  I know it works well this way, because my workstation 
is built like this.

However, I'm open to suggestions as well.

--

Tim Harrison
tim@linuxstep.org
http://www.linuxstep.org/