Status and outlook of LSB and FHS compliance of Fedora.

[David Kewley]

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