On Mon, Feb 07, 2005 at 05:21:34PM -0500, Jeff Licquia wrote:
> On Mon, 2005-02-07 at 17:07 -0500, Branden Robinson wrote:
> > Is this really necessary?
> >
> > * discover can be successfully run by mere mortal users (it's no more
> > administrative than lspci is, which lives in /usr/bin);
> > * who has /sbin but not /bin in his or her $PATH?
>
> I've heard complaints either way.
Yeah, that's pretty much inevitable. I argue the way I do because:
1) The command does not require administrative privileges to operate in
a successful and useful manner; and
2) Its manpage is in section 1, which itself suggests a "user command",
not an "administrative command"[C].
> My motivation for doing this was entirely for maintaining coherence
> with discover 1, which puts discover in /sbin.
Moving from {/usr,}/bin to {/usr,}/sbin is more disruptive than the
other way around, for the reason I noted above "who has...?".
I personally advocate coherence with documented standards than with
legacy implementations, especially when a transition to satisfy a
standard is pain-free (as you note, it isn't quite pain-free in this
case -- see below).
Here's what FHS 2.3[A] says:
/bin contains commands that may be used by both the system administrator
and by users, but which are required when no other filesystems are
mounted (e.g. in single user mode). It may also contain commands which
are used indirectly by scripts. [1]
[...]
Utilities used for system administration (and other root-only commands)
are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains
binaries essential for booting, restoring, recovering, and/or repairing
the system in addition to the binaries in /bin. [18] Programs executed
after /usr is known to be mounted (when there are no problems) are
generally placed into /usr/sbin. Locally-installed system administration
programs should be placed into /usr/local/sbin. [19]
Since the kernel may need discover's help to learn how to talk to the
hardware behind which /usr resides, I don't object at all to having
discover be in /{s,}bin.
For me, the question is "to /bin or /sbin?".
discover is clearly a command that "may be used by both the system
administrator and by users". It's certainly not a beast like init,
which is about as administrative as you can get, and it's not even an
arguable case like ifconfig[B].
> Evidently, mkinitrd does stuff with discover, and needs to
> know where it belongs, so there's more to it than just $PATH. (See bug
> 287189 for the details.)
Well, that sucks.
IMO mkinitrd is buggy. I suspect it's written the way it is because
Herbert Xu was involved in the perenneial flamewar about the
"POSIX-compliant" way to find the path of an executable. I don't intend
to recap those arguments here -- they can be found in the archives of
the debian-policy mailing list.
It's mkinitrd's problem because mkinitrd needs to solve the problem of
finding the paths to commands *somehow*, and instead of getting into
fights with Clint Adams and Tollef Fog Heen, among others, apparently
Herbert Xu just didn't solve it at all.
PGI had the same problem -- hardcoding paths to stuff on the system to
put in the live filesystem on the CD, I should note. I thought it was
gross and hated it then, and I still do. I never got the opportunity to
fix it in PGI, but that doesn't mean I endorsed the behavior.
> But I have no problem moving it, if we can agree on where to move it.
> Complaints prompted it moving to /bin, to /usr/bin, to /usr/bin with a
> static version in /bin, and now to /sbin; I do not feel like moving the
> binary with every package upload.
I understand your reluctance. In exchange for moving it back to /bin,
where IMO it belongs, I offer to serve as your human shield in further
arguments on this issue. :) I'm ready to go to the mattresses in
defense of my interpretation of the FHS, until and unless your critics
can summon Dan Quinlan, Christopher Yeoh, or Rusty Russell to trump it.
> (Frankly, I am becoming convinced more and more that a do-it-all binary
> "discover" is a bad idea, and am considering rewriting discover-modprobe
> in C and moving discover back to /usr/bin.)
I agree. The discover binary is warty and complex. IIRC, the only
reason it exists was as a migration path from Mandrake's "detect" tool.
It may be that Discover's command-line tools should be small suite of
lean apps, rather than one tool with several modes of operation and
three dozen options no one can remember. My sentiment is inspired not
just by discover, but by gpg, whose usage message I have to read *every
time* I try to use the silly thing. I wrote shell aliases to remember
some of the most common operations for me. The fact that I had to do
tells me that the command is violating Unix tool design philosophy.
Thanks for listening.
[A] http://www.pathname.com/fhs/pub/fhs-2.3.html
[B] I think ifconfig should be in */bin because it's perfectly useful as
a query tool, but you *can* change the state of the system in a
serious way with it -- though you have to have extra privileges to
do so -- so I can see why people argue for its continued existence
in */sbin. They're still wrong by the letter of the FHS, though, as
the command itself is not "root-only". The command simply lets you
do more things if you are root. If that alone is a reason to put
commands in /sbin, then let's move rm and cp there as well, because
mere mortal users can't change files or directories they don't have
permissions to modify.
[C] Whether there should be a hard mapping between */bin and manual
section 1 and */sbin and manual section 8 is an orthogonal argument
which I don't want to have in this thread. :)
--
Branden Robinson | GPG signed/encrypted mail welcome
[EMAIL PROTECTED] | 1024D/9C0BCBFB
Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C
| 72E8 0F42 191A 9C0B CBFB
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
