Re: traceroute in /usr/bin, not /usr/sbin
On Thu, Jun 14, 2001 at 08:24:25AM -0500, Vince Mulhollon wrote:
> On 06/14/2001 07:48:03 AM Craig Sanders wrote:
> >> in other words, you think that avoiding arbitrary and unnecessary
> >> breakage that serves no useful purpose is a "sorry excuse", that it's
>
> The useful purpose is fixing a FHS non-compliance bug.
a) that's a matter of subjective interpretation, not objective fact.
b) it's not a *useful* purpose, it's an *aesthetic* purpose
on the one hand we have subjective interpretation that traceroute
belongs in /usr/bin.
on the other hand, we have the objective fact that arbitrarily moving
binaries from the location they've been in for years will cause
breakage.
if your priorities put aesthetics above breakage (i.e. form above
function, image above substance) then your priorities are seriously
screwed up.
> Or the purpose is making the system more usable for users.
so add /sbin and /usr/sbin to the default PATH. there's no good reason
not to, and there is ample evidence that it does not cause any breakage.
> The fact that other packages have had to exhibit breakage to "work
> around" this package's breakage, is hardly a glowing recommendation to
> keep things broken.
i'm not talking specifically about other packages. packages can be fixed
readily enough.
i'm talking about locally written and/or installed scripts, especially
CGI scripts like Looking Glass or the many versions of traceroute.cgi
scripts which expect traceroute and other binaries to be in a specific,
hard-coded location.
> >> OK for stuff that used to work perfectly suddenly stops working after
> >> an upgrade - even when no new features have been provided, no actual
>
> New features have obviously been added.
> 1) Easier for non-root to use a "non-root" utility
if that's desirable, then do what i and many other people do: add the
sbin directories to the default path.
doing that works, it provides all the benefits of moving the binaries,
and it doesn't risk breaking anything.
> 2) Better FHS "compatibility", for whatever that's worth.
>
> It's easier for an admin to find an fix a path issue after this bug is
> fixed, than it is for a user to fix their path issues because of this bug.
> Because of that, the "total pain and suffering" will overall decrease when
> this bug is fixed.
users who don't know how to change their PATH don't know enough to make
any useful interpretation of traceroute's output.
having to edit local scripts on dozens of systems to cope with an
arbitrary and unneccesary change is a lot more "pain and suffering" than
merely changing the PATH.
it's trivial to edit /etc/profile or whatever to change the default
path. finding and fixing every script which runs /usr/sbin/traceroute
(or other sbin program) is a tedious, non-trivial task which is
difficult or impossible to automate.
> >> an upgrade - even when no new features have been provided, no actual
> >> bugs have been fixed...the only change is that it suits *your* aesthetic
>
> Obviously this "actual bug" would be fixed.
what actual bug?
you mean YOUR subjective intepretation that traceroute belongs in /usr/bin
rather than /usr/sbin?
that's not an actual bug.
by your interpretation, every program in /sbin belongs in /bin and every
program in /usr/sbin belongs in /usr/bin - because they all can be run
by users.
ifconfig, for example, is a useful diagnostic tool which lets users find
out the IP address(es) and other details of the machine's interface(s).
users have as much legitimate need to know those details as they have to
know what path their packets take. i'm not being sarcastic here, they do
have a legitimate need to know these things, however there is nothing
which actually stops them from running these programs now and thus no
compelling need to cause breakage.
> >> bugs have been fixed...the only change is that it suits *your* aesthetic
> >> sensibilities better.
>
> Please don't make it a personal aesthetic issue.
why not? that's exactly what it is.
> Its more an issue of following the FHS, and responding to user problems.
it's a subjective interpretation of the FHS.
> I guess you could say my aesthetic is to follow the FHS and help the users,
> which not an evil goal, nor is that goal limited to one person (me)
s/the FHS/your interpretation of the FHS/
> >> if it bothers you, then make a symlink. or add /usr/sbin to your path.
>
> The proper solution to a bug in a package is not to fix it for yourself,
> and not distribute the fix.
so get debian's default PATH changed. there's no good reason for the
sbin directories to be excluded from the path.
> >> ps: please check the archives before re-iterating the same tired
> >> arguments. we've seen this flamewar too many times before. it's boring
> >> and tedious. find something useful or interesting to do with your time.
>
> We have not seen it enough times, because it is not fixed. We will never
> see the end of this argument, until this bug is fixed.
it's not fixed because it isn't a problem. it's a matter of subjective
interpretation.
we will never see the end of it because a non-problem has no chance of
ever being 'fixed'.
> Believe me, it's at least as boring and tedious for the victims of
> this bug to work around and try to fix, as it is for you supporters of
> this malfunction to fight against progress.
it's not a bug or a malfunction.
add the sbin directories to your path, your system's default path, or
get them in debian's default path.
> Now that I've complained enough, here's my useful contribution to the
> debate. It's obvious that this bug causes problems for some people.
> Assuming this bug were fixed, and breakages in other packages that
> depended upon this breakage were fixed, in other words, once the dust
> settles, what is the disadvantage?
the disadvantages are that:
a) it breaks local scripts which depend on it being in a specific location
b) the "reasoning" that requires it to move to /usr/bin also requires that
many other programs are moved from *sbin/ to *bin/ - which will break many
other packages and local scripts.
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: