[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: base directory spec
- From: Filip Van Raemdonck <mechanix debian org>
- To: Waldo Bastian <bastian kde org>
- Cc: Havoc Pennington <hp redhat com>, xdg-list freedesktop org
- Subject: Re: base directory spec
- Date: Mon, 9 Dec 2002 11:12:30 +0100
On Fri, Dec 06, 2002 at 10:45:59PM +0100, Waldo Bastian wrote:
> On Friday 06 December 2002 21:54, you wrote:
> > On Fri, Dec 06, 2002 at 09:29:54PM +0100, Waldo Bastian wrote:
> > >
> > > I don't understand why you would want to say: "applications.menu must
> > > either be host-specific or user-specific." What's wrong with having a
> > > shared version under /usr/share?
What good is it to put it there if it can't be changed for configuration
If you leave it only there upon initial install and don't copy into
/etc, it'll confuse the hell out of any system admin who's looking to
set a system wide default, and even more so of a less proficient home
user who wants to set the default menu for his mom, sister, dog and
If you do copy into /etc immediately, the /usr/share one will only take
If the supposed benefit is for large machine parks and sharing, the
people needing and using that will have far larger issues to deal with
and will have to find a way to keep /etc in sync across machines anyway.
Also, such environments are more likely to have specialized setups with
entire hierarchies (including /etc) rooted somewhere on a server rather
than just sharing /usr/share. TBH, the whole "/usr/share must be able
to be shared" idiom is a nice thing to say, but not a very practical one
in reality. A more realistic approach is to share /usr/share/man and
And come to think of it, even in such environment configuration settings
are host specific rather than shared. Sure, a group of host may share a
similar situation, but unless you share that data (which is what
/usr/share is) and your shared version of the configuration file from
a host in that group rather than a server, chances are it'll be out of
sync anyway with the actual applications installed on the hosts.
> > What I was thinking is "/etc is for configuration, /usr/share is for
> > data" such that any given file would belong in sysconfdir or datadir,
> > not potentially both.
> > Reading the FHS, I don't see anywhere else to put shared configuration
> > other than /usr/share, so I understand now what you are saying.
What do you mean with "shared configuration"? As explained above, I
believe there is no such thing.
And how do you get to the conclusion that any configuration at all
should go in /usr/share?
FHS specificically says "The /usr/share hierarchy is for all read-only
architecture independent data files."
I wouldn't say configuration qualifies as data, nor as read-only. And it
can indeed even be arch dependent (although it usually won't be).
> > Is DESKTOP_DIRS used only for configuration? e.g. if I have some data
> > files, I don't know, say desktop backgrounds (/usr/share/backgrounds
> > or some such), would I put a host-specific background in /etc?
> Sure, why not?
> > The FHS would seem to ban that on the grounds that it's not
> > configuration.
Well, as Havoc said, because it's not configuration but data :-)
I first thought when reading the above that the example was a case of
eliminating real configuration (and thus flexibility) in favour of
spec'ing out where data is to be read from by apps (a bad idea IMO).
But I now just realize that maybe you're just talking about putting
backgrounds some place common so all tools can look them up and present
them as a choice. In that case, they definitely are not configuration
and the system local files should go somewhere under /usr/local
(/usr/local/share?). Which adds yet another location to go look in :-/
As a programmer, that extra directory is definitely a PITA. Especially
because upon first glance it makes a difference between system specific
configuration and system specific non-configuration files (and apps, but
we're mostly talking about data here).
But as a system administrator, I like /usr/local *a lot*. I can put
system local data and none-vendor provided applications there knowing
the package manager will leave it alone. And with a sane default search
path (in the spec) in absence of $DESKTOP_DIRS, or by explicitly setting
it if must be, even a distribution provided app will present / pick up
the data files put there.
> > Making a little table:
> > Host-specific Shared Arch-specific
> > Configuration sysconfdir ? ?
> > Data ? datadir pkglibdir
> > Is there a well-accepted thing to put in the "?" cells?
I'd *always* put configuration in /etc (save user-specific one).
Host-specific data, as outlined above, would be put either in
/usr/local(/share) or in some random unpredictable place depending on
who's the admin, in which case you can't make sure it is in the default
$DESKTOP_DIRS path anyway.
Unless you mean the distribution provided data by "host-specific", in
which case it'll probably end up in /usr/share.
> In KDE we use $KDEDIR/share/xxx (shared) and $KDEHOME/share/xxx
> (user-specific) for the various sorts of data and config is a special case of
> that in the form of $KDEDIR/share/config and $KDEHOME/share/config.
Which could be considered reasonable for ISV (=KDE in this case) provided
binary packages, which may go in /opt (but as usual, the system admin is
to have the final decision) and shouldn't need anything outside of
Which isn't reasonable for OS vendor provided packages if they end up
installed all over /usr. 
> If you want to include host-specific locations I think you have the choice of
> either saying
> a) /etc/xxxx is part of DESKTOP_DIRS. Then both config as well as other data
> could be stored under /etc as well.
But data doesn't belong there... And in the case of a small root and
separate /usr it actually becomes a serious problem.
> b) /etc/xxxx is not part of DESKTOP_DIRS but config data is looked up under
> both DESKTOP_DIRS and /etc/xxxx. In that case I would start with reserving a
> specific location under DESKTOP_DIRS for config data, e.g.
Which doesn't make sense, as it's configuration, and should be in /etc.
Considering the /etc/opt thing I'm believing the FHS people clearly want
*all* configuration in /etc (note that in their example /usr/local tree
there also is no /usr/local/etc) and both as a system administrator or a
system administrating user I'd also want it all there.
I think the best default fallback (preference-ordered) for $DESKTOP_DIRS
for configuration files is:
and for data files:
Rather than saying, we're unnecessarily differentiating non user specific
configuration and data, I'd call it a lucky accident that the user
specific part of those search paths are shared. Or perhaps it's an
unlucky accident and should we differentiate between user configuration
and user data. That may be a good idea anyway to avoid collision between
user configuration file names and data file names.
Oh, and I too vote for eliminating $DESKTOP_DIR as discussed in the other
 Reading FHS after writing this, actually it isn't - it should be put in
 Yes, according to FHS /opt is fine even in that case. But  remains.
Linux/PPC - where iMacs become real men's computers.
[Date Prev][Date Next] [Thread Prev][Thread Next]