Hello,
On Mon, Jun 25, 2001 at 10:32:19PM +1000, Anthony Towns wrote:
> The maintainer considers it solid enough. Guess whose opinion counts.
*sigh* The Technical Committee's? The maintainer does not seem to have
absolute discretion here, while you are making it sound like they do. It is
my understanding that "must" means exactly that, that a package that breaks
a "must" directive will generally not be permitted in the distribution. If
we want to allow exceptions (as is reasonable), we should specify that in
Policy itself (unless, as I have been asking[1], but no one has argued, that
is already implied in Policy). It is by no means clear to me why traceroute
is permitted to violate a "must" directive when it could comply with a
simple symlink or wrapper.
> Curiously, I don't think anyone's yet given an example of a Unix where
> traceroute's actually in /usr/bin. No doubt someone'll create a new
> "TracerouteInUsrBinLinux" shortly.
No need. 5 minutes on a search engine yielded these references. The
following apparently have traceroute in /usr/bin:
Slackware 3.x
<http://support.bb4.com/archive/199805/msg00006.html>
<http://ftp.man.olsztyn.pl/pub/linux/distributions/slackware/slackware-3.3/contents/tcpip>
AIX 4.1
<http://support.bb4.com/archive/199805/msg00023.html>
(I subsequently verified that traceroute is in /usr/bin for AIX 4.2 and 4.3,
as well, but you don't have to believe me.)
But does that matter? Not to me. The point (to me, I must admit) is
not that peer pressure dictates that we should do one thing or another (or a
symlink/wrapper), but that we have promised to follow the FHS[2], which says
exactly one thing with regards to traceroute[3] (at least as clarified by the
co-editor[4]).
> But let me rephrase anyway: traceroute's in /usr/sbin because that's where
> it is in a majority of other Unices, a majority of other Linux distributions
Granted. So let's allow for maintainer discretion in -policy. Changing
the FHS policy from "must" to "should" should do.
> and where it's always been in Debian. Moving it would break numerous scripts,
> for a benefit which can easily be obtained by adding a symlink locally, or
> changing your PATH.
Or adding a symlink/wrapper to the package and forestalling this whole
argument without breaking anything at all.
I also note that while adding a symlink locally may have the benefit of
FHS compatibility (although I am not clear on the FHS' stance on such user
intervention), changing one's PATH does not, so the benefit is not really
equal.
> This isn't a policy issue; it's a maintainer's discretion issue.
Since the question to be resolved is whether Policy grants the
maintainer the discretion to violate Policy in the absence of extraordinary
circumstances (and/or if such circumstances exist in this case), I
respectfully submit that this is a Policy issue, for clarification at the
least.
Rene
Footnotes:
[1] <http://lists.debian.org/debian-devel-0106/msg01006.html>
[2] <http://www.debian.org/doc/debian-policy/ch-opersys.html>, and
<http://bugs.debian.org/98291>
[3] <http://www.debian.org/doc/packaging-manuals/fhs/fhs-3.10.html>
[4] As reported in <http://lists.debian.org/debian-devel-0106/msg01005.html>
--
+--- (Rene Weber is <rene_autoreply@elvenlord.com>) ---+
| "Technology and privacy are antagonists. And I love them both." |
| Sam Lepore, San Francisco (as reported in RISKS 19.29) |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
Attachment:
pgpf1NVhqP4ZJ.pgp
Description: PGP signature