discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GNUstep directory layout


From: Dennis Leeuw
Subject: Re: GNUstep directory layout
Date: Fri, 06 Sep 2002 22:00:48 +0200

Hi Tim,

Just to clear up some stuff:

Tim Harrison wrote:

> 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.

That might be an option too. But I don't see any argument for not moving
DocumentTemplates into the Documentation directory. I guess Documentation and
Documentation/Templates is clearer, then Documentation and DocumentTemplates on
the same level. Next to that document templates are actual documents, but I
think I said that before... ;-)


> > * 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.

So I guess we agree on this. The should be a /Local/Users (nor argueing on the
amount of accounts that should be present there) and /Network should be kept
clean so a sysadmin can decide how to populate /Network.

While I write this I can almost hear Nicola scream with terror. How should he
implement this in his make files. How do we need to search the /Network
architecture without too much overhead for e.g. applications to run.

I think a little config file is needed for that. Like an entry in the defaults
db where a sysadmin can tell to the system what the search paths are and that
GNUstep.sh/.csh can use to set $PATH or something like that.


> > * 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.

Yep. I understand the confusion. But I am afraight that Servers will add to this
confusion, when is something a server. is X11 a server or is it a client. A
Tool, a App or a Server.
The split between App and Tool is not a clear one but gives the user an idea
what he might expect and probably what is expected from him/her. For Tools he
needs to get to the console, for Apps he can say in his save graphical
interface. It's all about user perspective, not if it is technically or
syntactically right.

>
>
> > 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
>

I know that document :-) But is that the GNUstep vision. Is that what Adam or
any of the other developers mean?


>
> > 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?

I completely agree. It was just meant as an idea for someone that tries to build
a complete GNUstep system.
For me it is quite simple. I have my normal users use /home/<username> and those
that want to use GNUstep get /usr/GNUstep/Local/Users/<username> as their home,
and yes I adjust /etc/passwd for that, or actually an adjusted adduser script
does that for me :-)

Greetings,


Dennis Leeuw





reply via email to

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