Hi Aaron,
Good discussion, thanks for pushing it. ;)
I think it's most instructive to see what the FHS itself says about its
purpose and scope. For me, that guides the clarification of many of
the issues we're raising.
The Introduction/Purpose section of FHS 2.3 states, in part:
> The FHS document is used by:
>
> * Independent software suppliers to create applications which are
> FHS compliant, and work with distributions which are FHS
> complaint,
> * OS creators to provide systems which are FHS compliant, and
> * Users to understand and maintain the FHS compliance of a system.
> The FHS document has a limited scope:
>
> * Local placement of local files is a local issue, so FHS does not
> attempt to usurp system administrators.
> * FHS addresses issues where file placements need to be coordinated
> between multiple parties such as local sites, distributions,
> applications, documentation, etc.
With that as context, I reply below.
Aaron Bennett wrote on Friday 04 June 2004 14:22:
> How do you reconcile the thought that /opt an optional place to
> install add-on software packages with what the FHS says about
> /usr/local?
>
>
> > /usr/local : Local hierarchy
> >
> >
> > Purpose
> >
> > The /usr/local hierarchy is for use by the system administrator when
> > installing software locally. It needs to be safe from being
> > overwritten when the system software is updated. It may be used for
> > programs and data that are shareable amongst a group of hosts, but
> > not found in /usr.
> >
> > Locally installed software must be placed within /usr/local rather
> > than /usr unless it is being installed to replace or upgrade
> > software
> > in /usr.
> >
> >
> >
> I suppose that could best be read as "/usr/local" is machine specific,
> while /opt is exportable and mountable. At least that's how a Solaris
> SysAdmin would probably take it. But it's pretty wierd if that's the
> case: it's ok to dump stuff into /usr/local/bin , but everything in
> /opt needs to be in /opt/<packagename>/bin ? Why?
I agree this is a bit weird, but I don't think it's something that
Fedora or RHEL or we as sysadmins need to worry about much. I could
make some guesses as to usefulness, but I won't. ;)
I read it as saying:
* The OS distributor MUST NOT put anything in /opt or /usr/local
except the required subdirectories.
* Third-party packagers MAY put things in /opt, but nowhere else,
and MUST follow the mandated structure in order to maintain
expectations.
* The sysadmin MAY put things in /usr/local or /opt, with structure as
suggested, but SHOULD NOT put anything (exceptions noted) into / or
/usr.
* Here (...) are some guidelines about what the sysadmin MAY like to
do to maintain expectations (including placement, directory
structure, and exporting), but we aren't saying that he MUST do
this -- it is totally up to his/her judgement.
> The best answer I can come up with is that the people at FHS didn't do
> any better job of grappling with this then I am. There are two
> issues: what is an add-on, and where should it go? I suspect that in
> RHEL world -- and you'd have to ask Red Hat RHEL product support for
> an answer -- anything that is not distributed by Red Hat is an add-on.
> Here in Fedora world we have the Fedora Extras repository which is
> sanctioned by Red Hat but not distributed or written by them. It's
> more of a grey area. What about stuff from livna.org, that according
> to Red Hat doesn't officially exist? Is xmms-mp3 and 'add-on'? Or a
> locally installed software package?
>
> Those are tough questions.
The FHS mandates where add-on software MUST go. The question, as we all
agree, is what is "add-on software", and I've never seen any
clarification of that from any quarter. Frankly, things work fine for
me as they are, so I have no complaint so far.
The FHS does NOT not mandate where the sysadmin MUST put things -- it
only gives suggestions. This is consistent with the FHS sections I
quoted at the top.
I see two useful purposes of this thread:
1) Discuss an interesting and semi-important topic so we can figure out
what the issues are, and possibly adjust our opinions.
2) Figure out what Fedora should do (with consideration of what RHEL
should do, as well).
I think (1) is great, so long as the thread doesn't get overly long.
As for (2), I think Fedora (and I assume RHEL) are doing just fine as
far as the FHS goes, given the uncertainty about what "add-on software"
means. Certainly (I presume) they at least pass the FHS test suite,
which is all that is truly required.
If there is any issue at all (and I'm not convinced there is, at least
not practically), then it is not in Fedora's court to fix it. It is
for the add-on software packagers to fix, and for sysadmins to
optionally fix. Fedora can set the playing field, but it cannot
mandate what all the players do. The FHS does not demand that of
Fedora.
> What I think happened with the FHS is it's trying to be all things to
> all systems. There are times when installing everything into /opt is
> a good idea. There are times when it's not. There are times when
> installing stuff into /svr is the right way to go... and times when
> it's not. I think that it's totally valid to have standard, canonical
> locations for files. I'm in favor of a Filesystem Hierarchy Standard.
> Just not necessarily this one. Whatever one we use, it has got to be
> consistent. We can't be moving stuff from /var/apache to /var/httpd
> to /svr/httpd to /services/webserver to /services/something else every
> two years.
By the way, a couple of folks on this thread have been writing '/svr'.
It's actually '/srv'. :)
Aesthetically speaking, I like /srv, and I plan to implement it on the
systems I manage, starting now. It seems to me to clarify where server
data is. Some of my colleagues have been using a made-up directory,
/infosys, for just such a purpose. I like /srv better, because it's
more suggestive, shorter, and stands a chance of becoming a wider
standard.
As for practical issues of upgrades and dragging the world along, well,
I'm glad that I don't have to make those tough political and distro
design decisions. ;) I don't think I have anything useful to suggest
right now.
I see the FHS as a work in progress, which isn't expected to be totally
consistent or complete at first. I see part of its use as suggesting
controversial but possibly useful things like /srv. I do not think
that Fedora needs to worry about whether or not the FHS is
self-consistent (except insofar as we want to influence the future
development of the FHS). Fedora only has to worry about whether or not
it passes the current FHS test suite.
Perhaps the FHS folks should try to adopt RFC-like MUST/MAY/SHOULD etc.
language, and specify *who* those verbs apply to in each case. That
could help greatly to resolve confusion, and to focus debate.
David
