Re: horse carcas flogging (was: traceroute in /usr/bin, not /usr/sbin)
Great, this argument again.
On Thu, Jun 14, 2001 at 05:50:13AM -0800, Ethan Benson wrote:
> look, you are flogging a dead, desiccated corpse of a horse here. the
[...]
> either that or ITP traceroute-bin or traceroute-fhs which puts it in
> /usr/bin. because the main traceroute package is never going to
> change.
Don't think that I'm not seriously considering this (making a package
that makes a symlink, that is). Is there anything else that such a package
might do? What if I called it "fhs-compatibility" and used in to "fix"
(probably just with symlinks for minimal impact) all such problems? Are
there any other files that are in FHS-illegal places that could benefit from
a symlink to the proper place (some not-serious suggestions have been
advanced[1])? I don't think I have yet read an argument that traceroute is
in the "right" place, the only arguments that I've noticed are that (a)
moving it would entail breakage[2], and (b) by strict interpretation of the
FHS, there are other binaries that must move[3] as well (presumably the
argument is "so until they are fixed, traceroute should stay where it is").
Given that the maintainer does not seem to be willing to consider making
the symlink in the package himself, this seems to be the only option that
does not require our users to make modifications to Debian itself (I am
usually reluctant to pollute the vendor's /usr/bin [etc.] directory in case
I cause a collision later, and at least some people think that changing the
default path for all users can be nontrivial[4] -- is there a reason why
$PATH is not set in /etc/environment for pam_env and removed from the
shells' startup files, BTW?).
Advantages of a package to "correct" the placement of traceroute:
- Those that think that symlinks are messy[5] don't have to have them
inflicted on their system.
- FHS compatibility, as we have promised[6].
- Easier for users to run traceroute (lest we forget what this whole
discussion is about).
Disadvantages:
- Will probably not stop this incessant argument since I doubt traceroute
will suggest "traceroute-fhs" (or whatever it is called) so people may not
be aware of the package, and it's by no means an optimal solution in any
case.
- Yet Another Package.
- Codifies into permanent form a recurring Debian Argument (that is, it
looks bad that the only way to resolve this is to supply a second package
to patch the first (internal) package). This would be somewhat mitigated
if it were a system-wide "fhs-compatibility" package rather than just one
to "fix" a single package.
- The symlinks will be backwards (the traceroute binary should be in
/usr/bin and the symlink should be in /usr/sbin pointing to
/usr/bin/traceroute since it is just there to prevent breakage).
Comments? Is this worth thinking more about? If so, just
"traceroute-fhs", or a whole "fhs-compatibility" "package"? Does anyone
really think that /usr/sbin is the correct place for traceroute to be (as
opposed to thinking that it should stay there for historical reasons or
inertia)? I find it hard to believe that anyone thinks that traceroute is
typically "used exclusively by the system administrator."
Rene Weber, who dislikes the idea of large fields of symlinks pointing from
/usr/bin to /usr/sbin, but whose interpretation of the FHS is that
traceroute at least should be in /usr/bin. Alternative readings of the
FHS are welcomed, as are attempts to get the FHS changed and/or
/sbin and /usr/sbin added to the default $PATH.
References:
[1] <http://lists.debian.org/debian-devel-0106/msg00775.html>
[2] <http://lists.debian.org/debian-devel-0106/msg00768.html>, for example.
[3] <http://lists.debian.org/debian-devel-0106/msg00781.html>
[4] <http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=65611>, and
<http://lists.debian.org/debian-devel-0006/msg01386.html>, for example.
[5] <http://lists.debian.org/debian-devel-0106/msg00788.html>
[6] <http://www.debian.org/doc/debian-policy/ch-opersys.html>, and
<http://bugs.debian.org/98291>
--
+--- (Rene Weber is <rene_autoreply@elvenlord.com>) ---+
| Nothing is worse for people who are busy than visits from |
| people who are not. |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
Reply to: