Re: traceroute in /usr/bin, not /usr/sbin
Hello,
On Sat, Jun 16, 2001 at 10:31:16PM +0200, Wouter Verhelst wrote:
> There are two camps in this discussion. One camp that thinks traceroute is
> fine where it is right now (namely in /usr/sbin) and one camp that thinks
> it belongs in /usr/bin. The latter camp argues that this would be more
> FHS-compliant. The first camp argues that perhaps FHS says traceroute is
> not an admin tool, but that the same goes for lots of other programs in
> /sbin and /usr/sbin, that it would be unfair to say that only traceroute
> should be moved, but that all those other programs can stay where they
> are.
Please note that this is mostly a straw man argument. I think most
people in the "traceroute should be moved" camp agree that we should
evaluate other programs in /usr/sbin. The only reason why I am using
traceroute as the example is because it is the one the original complaint
was about.
A more compelling argument (to me) would be that moving everything would
be too disruptive, or that having large numbers of symlinks is too messy.
However, I don't see anyone in the "leave traceroute where it is" camp
arguing either of those.
> Personally, I don't think ifconfig and traceroute can be considered the
> same type of tools. Agreed, traceroute is usually used to do network
[...]
> I think that traceroute is a user tool. And that ifconfig is an
> administration tool.
I agree with most of what you say here, but it's not really relevant.
> The easiest argument to this would be: "FHS does not define administration
> tools this way, so if we do it that way, we're not FHS-compliant".
>
> Correct. But while it's a good thing to follow standards, no single
> standard should be looked at as the holy bible. In this particular case,
> we'd be following the definition for a *software category* as defined by a
> *filesystem standard*. A lousy definition, IMHO:
Yes, it's a lousy definition. I don't like it much either, although I
am hard pressed to think of a succinct easy-to-apply alternative. However,
in my view, the way to correct that is in the definition upstream. I don't
think Debian wants to say that we will embrace standards except where we
disagree and in those cases we will silently ignore what the standard says.
If we want to make an exception to this definition, let us allow for
that possibility in Policy by strengthening the maintainer's ability to
diverge from the FHS. At least that will admit that we are not prepared to
be FHS compatible yet. Currently, the only reasons a maintainer is
permitted to not comply with the FHS is if following the FHS would "violate
other terms of Debian Policy"[1] or, implicitly, if there is a serious
enough error that would permit the package to break Debian Policy. I don't
think either of these currently apply, so Policy should either be amended to
add a "after discussion on debian-devel" (or wherever) or "or would be
impractical or unreasonable" (as was proposed on [1] but apparently pulled)
clause so that maintainers can violate the FHS if necessary.
The latter, of course, would simply shift the discussion to if having
traceroute (for example) in /usr/bin (or with a symlink) "is impractical or
unreasonable."
Rene
References:
[1] <http://bugs.debian.org/98291>, is everyone sick of seeing this
reference yet?
--
+--- (Rene Weber is <rene_autoreply@elvenlord.com>) ---+
| "So the question really is this: How do you convince a young Yemeni |
| that a rhino horn dagger is not a symbol of your manhood, but a signal |
| of the fact that you need such a symbol?" |
| -- Douglas Adams & Mark Carwardine, "Last Chance To See" |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
Reply to: