Hello,
On Sun, Jun 17, 2001 at 12:23:49AM +1000, Craig Sanders wrote:
> the "traceroute belongs in /usr/bin because FHS says so" is based on a
> debatable interpretation of the FHS, and a highly debatable assessment
> of traceroute's status as a "user" tool rather than an "admin" tool.
All right, if you think it's debatable, then let's debate it! There has
been no debate on the subject (of whether the FHS mandates that traceroute
must move) on this thread yet that I've seen. What I've seen is people
pointing out that traceroute is useful to regular users, and the respondents
saying that many other things are as well. This does not refute the
original argument that traceroute is a user tool, it merely shifts the
debate to the question if it is too disruptive to move everything.
I also happen to think the FHS is completely clear on the subject that
user tools must be moved. If anyone disagrees, I'd appreciate hearing their
interpretation of the FHS directive in question[1] and how they think that
traceroute is "used exclusively by the system administrator."
> some people are saying that because traceroute CAN be executed by a user,
> that makes it a user tool.
>
> *exactly* the same can be said for ifconfig and dozens of other programs
> in /sbin and /usr/sbin.
>
> if the argument is valid for traceroute then it is also valid for
> ifconfig etc. if traceroute must be moved, then so must the others.
Great, so is the argument valid? Set aside for the moment the
disruption (and let there be no doubt, if the argument is valid, there will
be messiness and probably some disruption) and consider if the argument
alone is valid. First we have to decide if there is a problem *then* we
should worry about fixing it. Allowing the fear (that fixing it will be too
much work) to influence whether or not we think/admit there is a problem in
the first place is deeply flawed, as I hope is obvious.
You say that there is a question as to whether traceroute is a "user"
tool or an "admin" tool. Since the only relevant application of this
distinction to the current discussion is the meaning placed in the FHS
section 4.6[1], then I think we have a very clear criteria. If traceroute
is "used exclusively by the system administrator", then it is what you would
presumably call an "admin" tool. If not (thus, if it is used even
occasionally by regular users), then it is what you would seemingly call a
"user" tool. It seems clear to me that regular users use traceroute, so it
is a "user" tool. What's your argument?
> OTOH, if the argument is not valid for ifconfig then it is not valid for
> traceroute either. if ifconfig shouldn't be moved, then neither should
> traceroute.
Agreed, and I have already admitted (in previous mail to the list) that
this issue is larger than traceroute itself, but that does not change the
underlying question.
> the counter-argument is that it is irrelevant whether a program CAN be
> run by a user, it's status is determined by what it's primary use is.
This is a decent argument, but the FHS makes no allowance for that. It
determines (for the purposes of /usr/sbin at minimum) a program's status
based on the criteria that I keep quoting, if it is "used exclusively by the
system administrator." If you think this is a bad criteria, sure, take it
up on the FHS mailing list, or with the editors. But we are pledged to
follow the FHS as written, and as written, a program's "primary use" is not
relevant.
> there is also the fact that moving it will cause breakage.
Again, this does not address the underlying question, but at any rate,
the suggestion that we make symlinks does not cause any breakage. Your
statement that moving it will cause breakage is misleading, because I don't
think anyone is still proposing that we move it without leaving a symlink
behind (at least temporarily, which is measured on a large scale as far as
Debian is concerned).
> and, finally, the package maintainer believes that it is an admin tool
> which belongs in /usr/sbin
Fine. The package maintainer is at odds with (my reading of) the FHS.
Unless someone can argue that my reading of the FHS is fundamentally flawed,
or that there is a compelling reason why traceroute can break Debian Policy
(which is not out of the question, but I don't see any reason at all why
traceroute cannot be FHS compatible with the addition of a symlink), I think
the FHS should prevail.
> these claims have been made several times...and promptly ignored with
> large amounts of handwaving.
I'm sorry, but I have not seen any unrefuted claims that "the FHS does
not require traceroute be moved", nor that "the FHS is imprecise on that
question," in this thread anyways. What I do see is a lot of handwaving
(ie, 'it doesn't matter what the FHS says, look at all the damage that could
be done if we follow it'). Please either restate the claims that I request
above, or give me references to where they have been made before.
> this dead horse really doesn't need any more flogging.
So let's KILL it already! Ignoring might make it go away for now, but
there is no doubt in my mind that it will return. It will return and
persist because what we are doing is at odds with what we have promised. If
we are going to pick and choose what parts of the FHS with which we are
going to comply, then we must admit that explicitly in policy. This is not
a case of compelling need (such as a program that simply doesn't work, which
as aj pointed out[2] is a valid reason for a package to break Policy). One
of the arguments is that we should ignore the FHS because it is mandating
too many changes and would thus cause too much work for us to implement.
Does that really sound like a defensible argument to anyone? Does Debian
really not care about doing the right thing?
Does anyone anyone really object to making a symlink to /usr/bin for
traceroute to ensure FHS compatibility (and hopefully prevent this thread
from ever returning)? What about symlinks for all binaries in /usr/sbin
that shouldn't be there? That's messy, but the advantage of doing it in a
"fhs-compatibility" package is that it is easy to remove.
Let us resolve this this time, and not simply hope it goes away. We are
doing the wrong thing at the moment. It will return.
Rene, who would be happy if the symlinks were made or policy was changed,
but not with the inconsistency of the present situation.
References:
[1] <http://www.debian.org/doc/packaging-manuals/fhs/fhs-4.6.html>
[2] <http://bugs.debian.org/98291>
--
+--- (Rene Weber is <rene_autoreply@elvenlord.com>) ---+
| "Education is the ability to listen to almost anything without |
| losing your temper or your self confidence." -- R. Frost |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
Attachment:
pgpatwdV79ek7.pgp
Description: PGP signature