Hello,
I would like to ask the opinion of debian-policy readers on how to deal
with the discrepancy between Debian Policy and practice with regards to the
FHS and the use of /usr/sbin and /sbin. As I have argued extensively
elsewhere[1], Policy mandates that we "must"[2] follow the FHS and the FHS
has unequivocally stated[3] (at least in interpretation by the co-editor)
that traceroute (at least, and probably many other binaries that currently
live in /sbin and /usr/sbin) does not belong in /usr/sbin, while the
"traceroute" package (for example) puts the binary in /usr/sbin.
It seems to me that this is a serious problem, that the "traceroute"
package is violating Policy. Moreover, it seems that this state of affairs
is being largely ignored even though I have brought it up repeatedly on
debian-devel in the last week (and I assume that I am not the first person
to notice it).
So my question to the debian-policy readers is, is there a flaw in my
interpretation? Assuming that there is not, what is the best way to
reconcile it? I see two main options:
(1) Change policy to weaken the "must"[2] directive to a "should" if this is
possible before Policy really freezes. (I earlier noted that Policy is
mostly-frozen[4], but perhaps changes are still possible.)
(2) File serious bugs (I assume "serious" is the proper severity[5]) on
traceroute (as it is one that is most clearly in the wrong place, thanks
to the clarifying note from the FHS co-editor, although a consideration
of everything else in the sbin directories is probably necessary) to
have its location changed, or have symlinks/wrappers in place to
maintain FHS compatibility and non-breakage for existing programs.
Of these two, (1) is probably the easiest and the most likely to get done
before relevant things freeze, but it's a question for -policy if we
actually want to back off from the FHS (temporarily or not). (2) has the
advantage that it will probably stop the "traceroute should be in /usr/bin"
arguments that pop up on -devel far too often, but it means a change to
(probably) a lot of packages and I dislike the idea of filing a bunch of RC
bugs just before a freeze unless absolutely necessary. It also has the
disadvantage of littering the bin and sbin directories with
symlinks/wrappers, to which some at least have objected[6].
I have corresponded privately briefly with Herbert Xu (the maintainer of
the traceroute package), who objects to moving traceroute on the grounds
that since no other major Linux distribution has done so, the FHS may be
changed in the near future. On the subject the FHS co-editor said that
there were no short term plans to change the definition of the sbin
directories[2], but I sympathize with Herbert's concern. It seems to me
that a symlink or wrapper, however, is an acceptable compromise in this
case. Herbert has not yet responded to my suggestion that this is a way
out. This may have a bearing on the choice to change Policy (that is, if
there is a prevailing opinion that the FHS is not stable, then we may be
more disposed to back off from it).
I have no strong opinion either way what should be done, but I do
believe strongly that something should be done, otherwise we are releasing
Woody with a Policy that promises things that we are deliberately not
providing.
I am prepared to do the leg work (that is, drafting the minimal change
to policy or filing RC bugs/finding packages that are violating the FHS with
respect to sbin directories and considering them for RC bugs) if -policy
will help me to decide on the proper course of action.
It is also entirely possible that I have missed something and there is
no conflict between the "traceroute" package and Policy (I advanced the
possibility that "must" was meant to read "must, unless the maintainer
objects", or that prevailing opinion on debian-devel was meant to override
that of the FHS for example), but none of my appeals for arguments to that
end (or even the prospective arguments that I floated in the hopes that
someone would argue for them) yielded anything fruitful.
At the moment I am most concerned that we not commit ourselves to Policy
and then silently break it. Any arguments or clarifications to the end of
resolving that perceived discrepancy are greatly welcomed. Mail should
probably go to this list, but in the interests of avoiding the explosion
that happened on -devel, I am happy to collate mail sent directly to me as
well and report it back to the list.
Thanks!
Rene Weber
References:
[1] <http://lists.debian.org/debian-devel-0106/msg01005.html>,
<http://lists.debian.org/debian-devel-0106/msg00948.html>, and
<http://lists.debian.org/debian-devel-0106/msg01006.html>, for example.
[2] <http://www.debian.org/doc/debian-policy/ch-opersys.html> as modified by
<http://bugs.debian.org/98291>
[3] <http://www.debian.org/doc/packaging-manuals/fhs/fhs-3.10.html> as
clarified by the FHS co-editor as reported in
<http://lists.debian.org/debian-devel-0106/msg01005.html>
[4] <http://lists.debian.org/debian-policy-0106/msg00080.html>
[5] <http://www.debian.org/Bugs/Developer#severities>
[6] <http://lists.debian.org/debian-devel-0106/msg00953.html>
--
+--- (Rene Weber is <rene_autoreply@elvenlord.com>) ---+
| "One of the advantages of being disorderly is that one is constantly |
| making exciting discoveries." -- A. A. Milne |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
Attachment:
pgpuMlF9GNoNb.pgp
Description: PGP signature