Re: traceroute in /usr/bin, not /usr/sbin
On Sat, 16 Jun 2001, Rene Weber wrote:
> 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.
Of course. I forgot to explicitely mention that, but I would rather
suggest a better definition for administration tools to the maintainers of
the FHS document than diverting from it.
> 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.
That is also a possibility, but I would first try to have FHS discussed
outside Debian before we would act this way.
> 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."
Voila. And would set a precedent I would rather not see...
<snip>
--
wouter dot verhelst at advalvas in belgium
Try does not exist. Believe that you will do it, else you will fail.
-- Luke Skywalker,
in the trilogy "The Jedi Academy", Kevin J. Anderson
Reply to: