[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: traceroute in /usr/bin, not /usr/sbin

I hate to "flame" people, but almost every claim you made is illogical, or
kind of funny.  If you were trying to be funny, accept my apologies in
advance for taking your claims too seriously.  I generally hate smileys,
:), but perhaps <humor mode>humor mode</humor mode> would be appropriate to
highlight moods, etc.

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.
Or the purpose is making the system more usable for users.

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

>> 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
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.

>> 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.

>> bugs have been fixed...the only change is that it suits *your* aesthetic
>> sensibilities better.

Please don't make it a personal aesthetic issue.
Its more an issue of following the FHS, and responding to user problems.
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)

>> 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.

The proper solution to a bug in the package, is to ask the maintainer to
fix it, so all can benefit from your repair.

>> 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.

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.

I believe fixing bugs in Debian is a useful and interesting expenditure of
my time.

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?

I'm thinking there is no long term disadvantage, so fixing this bug results
in a long term net gain.


Reply to: