[fhs-discuss] on the /*/local/ hierarchies

Christoph Anton Mitterer calestyo at scientia.net
Sun May 15 04:42:02 PDT 2011


On Sat, 14 May 2011 19:57:20 -0400, toobuntu <toobuntu at gmail.com> wrote:
> I think what you describe for /etc/local belongs under /usr/local/etc. I
> would define /usr/local like you for software not managed by the package
> manager but built by the administrator
Well but then you run into troubles... namely:
If you say, /*/local/ is for not package managed software (which I fully
agree), than /*/local does not imply any locality of the data, thus it
would be perfectly valid, to have one shared network filesystem /usr,
including package managed software (managed on some other machine), an
non-package managed software (e.g. also installed on some other macheine).

But if you now put their global config in /usr/etc, this means, that all
of them have to share the same config.

IMHO, /etc should be really local.

Of course I'm aware, that if you actually use remotely installed software
(i.e. /usr on NFS or so),.. you'll get a empty /etc at first... but that's
something you'll have to deal yourself with).


>, and /opt for software not managed
> by the package manager and not built by the administrator (e.g. dropbox,
> nomachine, vmware *.deb's packaged by third party vendors).
That's the wording for a definition of "/opt" I was looking for :D


> For local machine configuration that diverges from the package manager's
> defaults, do we want to define a best practice? One idea is to leave
/etc
> in pristine form as the package manager leaves it and to use symlinks
from
> /usr/etc or /usr/local/etc.
In an ideal world that woul be definitely a good idea,... at least if you
mean, that software should put their defaults in /usr/etc (or
/usr/local/etc)... and only really user-modified config goes to /etc.
This would also solve the problems with /usr/etc I've mentioned above.

But honestly, I strongly doubt that this will ever happen,... as so many
software would have to adapt...
Again, I think this would be a clean solution,.. but we could end up in
now one adhering anymore to FHS.


> Also, I thought the "shared" part of the definition for /usr/share
refers
> to shared among multiple users of the local machine. The prior
discussion
> about this seemed to assume it means exported as a network filesystem.
Can
> we get more clarity about this?
I'd rather say this has nothing to do with network sharing and/or user
sharing,... but with "shared files" in the sense of architecture
independent files (e.g. resource files, and so on).



Cheers,
chris.


More information about the fhs-discuss mailing list