Hello,
This is a summary statement to indicate the resolution of my question
regarding the FHS policy and practice issue that I posted to debian-policy
last month.
In replying to one of my pieces of mail (and in subsequent
communication), Steve Greenland <stevegr@debian.org> and I have come to an
understanding that resolves my concerns with the apparent contradiction
between FHS policy and practice. Although this took place in private
e-mail, we thought it might be useful to bring this back on the lists so
that it would be documented somewhere in case it is relevant again. I have
Steve's permission to quote him here, and he has indicated his agreement
with the content of this summary.
On the subject of Rusty Russell's clarification of the FHS' directives
for /sbin and /usr/sbin, I believed that this was considered authoritative
due to the advice in Policy that the FHS author should be contacted for
clarifications[1]. I did question this assumption in a subsequent mail[2],
but no one took me up on that at the time. Steve later made the argument to
me that "the effect of such an exchange has the same affect on the FHS as an
exchange with a C Standard committee member on comp.std.c has on the ISO C
Standard: none at all," unless published as a defect report on the website
or incorporated into the standard itself.
If we reject or question the authority of Rusty's statement of
clarification, we are left with the FHS as published. On this subject,
Steve pointed out that the term "exclusively" (which we believe is the
sticking point for /usr/sbin and traceroute in particular) is used only for
/usr/sbin, but not /sbin, and that this disreprancy is not clearly
intentional. Moreover, the footnotes are inconsistent, #16 in section
3.14.1 of FHS 2.2[3] saying "If a normal user will *ever* run it . . ." in
the first paragraph, while saying that the "division [was created] between
binaries that everyone uses and ones that are *primarily* used for
administration tasks" in the third paragraph [emphasis mine]. While it is
not clear if footnotes are normative (although there is no statement about
that in the standard itself), this, combined with the previous discreprancy
is probably enough to be the basis for a reasonable objection to the clarity
of the FHS on this issue.
Steve has agreed to look into bringing this matter (and others) to the
attention of the FHS authors/list when he has the time.
In addition, the argument has been made[4] that Policy is meant to be
treated by maintainers as pliable, and that there is (or should be) an
implied escape clause, which would seem to imply that it is not an actual
promise to our users. This is not resolved or clearly the opinion of the
majority, but it is not necessary for this particular issue as the FHS
itself has been shown to be questionable. However, I feel that it would be
useful to have a statement in Policy as to whether it is binding on
maintainers or not (and in what circumstances a maintainer can break
Policy).
For the moment, though, I am satisfied that we are not unduly breaking
Policy with respect to FHS compatibility, and am happy to drop the matter
unless a compelling dissenting opinion is posted.
Rene Weber
References:
[1] <http://www.debian.org/doc/debian-policy/ch-opersys.html>
[2] <http://lists.debian.org/debian-devel-0106/msg01031.html>
[3] <http://www.pathname.com/fhs/pub/fhs-2.2.txt.gz>
[4] <http://lists.debian.org/debian-policy-0106/msg00308.html>,
<http://lists.debian.org/debian-policy-0106/msg00271.html>, and
<http://bugs.debian.org/102213>
--
+--- (Rene Weber is <rene_autoreply@elvenlord.com>) ---+
| "Few men speak humbly of humility, chastely of chastity, skeptically of |
| skepticism." -- Blaise Pascal |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
Attachment:
pgptd4TkweDCN.pgp
Description: PGP signature