Re: horse carcas flogging (was: traceroute in /usr/bin, not /usr/sbin)

[Rene Weber <rene_deblist@elvenlord.com>]

    Hello,

On Sat, Jun 16, 2001 at 10:07:13PM -0800, Ethan Benson wrote:
> no the problem with this part of the FHS is its hopelessly ambiguous
> and can be interpreted either way for EVERYTHING.   i could argue that
> adduser belongs in /usr/bin because a user can run `adduser --help'.  

    Fair enough, I agree with that (last statement at least) completely.  I
think that the FHS' definition for /usr/sbin is far too restrictive as well.
What I disagree with is that Debian can say that we are FHS compatible, but
then silently ignore parts of the FHS.  If we want to override parts of the
FHS, let us admit it!

> debian policy does not need to be changed, traceroute is NOT violating
> the FHS.  the maintainer of traceroute interprets traceroute as an
> ADMIN tool and thus it must be in /usr/sbin per FHS.  
> 
> just because YOU interpret it another way does NOT make you right and
> Herbert wrong.   BOTH interpretations are perfectly valid, thus
> there is no need for it to move since either way its compliant.  

    As I keep saying, the FHS has a clear criteria as to whether a program
belongs in /usr/sbin or not (hence, probably what you mean by an "ADMIN
tool").  We all seem to agree that it's a bad definition, but I have yet to
read an unrefuted argument that the FHS currently defines traceroute as an
admin tool that should go in /usr/sbin.  OTOH, I have made my argument and
reading clear why traceroute should not be in /usr/sbin (basically because
it is not "used exclusively by the system administrator"[1]).

    My reading is that a maintainer cannot (by the FHS) decide whether a
program is an admin tool without taking the directive quoted above into
consideration.  Someone please explain to me if I am wrong on that score and
people can define their programs in a way that contradicts the published
definition.  With references if applicable, please.

> if you don't like traceroute in sbin then take this useless discussion
> somewhere where it can make a difference: the fhs mailing list.  

    I have posed the question to the FHS co-editor.  His reply may shock
you.  However, it is not sufficient to take this to the FHS mailing list; we
are pledged to follow the FHS as written[2] except in exceptional
circumstances that no one (I think) has tried to claim.  If policy were
re-written to say that we will follow the FHS except in the case and
particular points of ongoing (Debian-sponsored?) discussion, then I would
agree that taking it to the FHS list would be sufficient.  As it stands, we
have to do something about existing policy and practice.

> debian can do NOTHING AT ALL to fix or change the FHS. as the FHS is
> currently written there is no clear answer to where traceroute really
> belongs.  you can't argue that traceroute is uncompliant since that is
> NOT clear.  

    The co-editor of the FHS disagrees.

> take this to the fhs list and stop filling our mailboxes with this
> endless bitching.  

    I hope this puts the matter to rest then.

    I sent a piece of e-mail to Rusty Russell <rusty@rustcorp.com.au>, the
co-editor of FHS 2.2.  In my mail, I made a good faith effort to summarize
the positions of both camps (as they were known to me at the time), and gave
him pointers to the mailing list archives and specific posts so that he
could research further if he wanted.  In the interests of full disclosure, I
also informed him the camp of which I was a member, stating that I believed
that according to the FHS, traceroute "must go in /usr/bin".  I asked him if
he could answer the following questions:

: (1) [If it] is likely that the rules for /usr/sbin will change in the near
:     future, or if you are satisfied with them as they are (if you can say
:     anything about this, of course -- the thrust of my question is if you
:     currently read the rules for /usr/sbin as they relate to this issue as a
:     mistake).
: 
: (2) If the current rules for /usr/sbin do dictate that traceroute (and
:     other binaries currently in /usr/sbin for Debian 2.2r3) must move
:     (perhaps to /usr/bin).  If necessary to answer this question in the
:     more general sense, a list of files currently in /usr/sbin for Debian
:     2.2r3 on i386 can be obtained on the web page.[reference removed]

Here are the relevant bits of his reply:

: Current:
: ================
: Let's look at the 2.2 wording for /usr/sbin:
: 
:         This directory contains any non-essential binaries used
:         exclusively by the system administrator.
: 
: Now, this is pretty clear: your interpretation is correct for
: traceroute, assuming traceroute is setuid (cf. ping).

    I believe that this is a strong statement that for traceroute at least,
the FHS mandates that it must not be in /usr/sbin.  I also take this to mean
that there is no maintainer discretion -- that is, that maintainers cannot
define the purpose of their programs (for the purposes of FHS compatibility)
in contradiction of the FHS' directives.  Alternate arguments that
maintainers do have (not *should* have, but *do* have) that freedom are
welcomed.

: Future:
: ================
: There is room for debate in FHS 2.3 over:
: 
:         1) Should /sbin and /usr/sbin really exist?
:         2) If it should, should ifconfig really be there?
: 
: My Opinion:
: ================
: 
: IMHO, (1) is questionable, but it's a compatibility thing, so almost
: certainly true.  But (2) has little merit, and removing the explicit
: mention of ifconfig would allow a distribution to place it in /bin.

    This seems to indicate that there are no immediate plans to change the
rules for /usr/sbin (since he only mentioned the existence of /sbin and
/usr/sbin, and the exception for ifconfig as being debatable, I assume that
the criteria for /usr/sbin is not in question), assuming /usr/sbin and /sbin
survive in the FHS.  Since he cites compatibility reasons and doubts that
they will be removed, this should allay Herbert Xu's stated concerns that
the rule for /usr/sbin will change in the future[3], at least as far as we
are able to predict the future.

    It seems to me that the only question remaining is if Debian is actually
committed to FHS compatibility, even in the case of what are arguably bad
decisions on the part of the FHS.  I would support and welcome a discussion
on the FHS mailing list to changing the definitions for /usr/sbin and /sbin,
but as written I think we need to make some changes somewhere (in Policy or
the packages in question) otherwise we are making claims and promises in
Policy that are simply not true.

Rene Weber

References:
[1] <http://www.debian.org/doc/packaging-manuals/fhs/fhs-4.6.html>
[2] <http://www.debian.org/doc/debian-policy/ch-opersys.html> and
    <http://bugs.debian.org/98291>
[3] <http://lists.debian.org/debian-devel-0106/msg00865.html> and
    <http://lists.debian.org/debian-devel-0106/msg00879.html>

-- 
+---           (Rene Weber is <rene_autoreply@elvenlord.com>)          ---+
| Genius, n.: A chemist who discovers a laundry additive that rhymes with |
| "bright."                               -- Manoj Srivastava's signature |
+---  E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/>  ---+