Re: traceroute in /usr/bin, not /usr/sbin
On 06/15/2001 05:09:12 AM Herbert Xu wrote:
>> Richard Kettlewell <rjk+news@sfere.greenend.org.uk> wrote:
>>
>> >> on the one hand we have subjective interpretation that traceroute
>> >> belongs in /usr/bin.
>>
>> > The FHS is perfectly clear, despite the attempts to claim otherwise.
>>
>> I never suggested otherwise. I am merely pointing out that no major
>> distribution has to date followed this rule.
Some say that feature "X" of MS-Windoze is broken because "Y", therefore
Debian should be equally broken. After all, no one else is following the
rules. If MSIE5 crashes, well then we better make a cron job that crashes
konqueror at least as often so we can be compatible.
Or closer to home, some claim that RPM's typically have weak and/or
inaccurate dependancies, thus Debian should also have weak or inaccurate
dependancies.
No major distribution follows "something like the DFSG" with such care,
thus Debian should be equally leniant and merge non-free into main.
I don't find the "peer pressure" argument to be a good excuse. "Everyone
else drinks and drives, so I should too."
>> Let me repeat this, if you want to argue that traceroute should be moved
>> on the grounds of FHS compliance, then you must move all the other
>> utilities that fall under it, that is, most things in /sbin and
/usr/sbin.
That's the right thing to do. Maybe in the future that will happen. And
if it is done to ensure compliance with Debian Policy and the FHS, thats a
good thing. Someone else posted a list of packages that must remain in
sbin, like init and so forth. It's not like sbin is going away because
traceroute is the only binary in it.
I recall something from the Policy Manual and the NM process that packages
should follow Debian Policy (and thus the FHS), I don't recall anything
about packages highest priority is to copy choices from other broken
distributions or copy choices from other broken packages. If you can give
me a citation from Policy that (clearly) explains that the highest priority
above all others is to be as broken as other packages or as broken as other
distributions, please do so.
I fail to see why other binaries matter. kbdconfig is not being debated,
traceroute is. It's nothing personal. Maybe next year there will be a
flamewar because scsiinfo is needed for users to do something. We'll burn
that bridge when we come to it, but at this time, the traceroute bridge is
burning.
Or are you saying something like : Developer Q hasn't fixed their 10
release critical bugs, that means its OK to ignore my 1 RCBug?
To make a silly comparison example using my interpretation of your
reasoning : Sendmail has a buffer overflow (purely a made up example, not a
real security claim), therefore I refuse to fix the buffer overflow in my
assembler package until sendmail fixes their bug, because they've set a
precedent, and after all, everyone has come to expect that overflow to be
where it is, and there's hard coded skripts that depend upon that overflow,
and only an admin would care about overflows anyway, besides RHAT's
sendmail has a buffer overflow too, so we need the same overflow to "keep
up" with RHAT.
Reply to: