Re: horse carcas flogging (was: traceroute in /usr/bin, not /usr/sbin)
Hello,
On Mon, Jun 18, 2001 at 01:29:24AM +0200, Manfred Wassmann wrote:
> The FHS isn't clear at all. It is totally ambiguos in this point becasue
> it doesn't define neither user nor system administrator. When you look
Now, that's actually a decent argument, thank you for bringing that up.
I contend that without a strict definition for "user" or "system
administrator", we must fall back on common usage (after all, the FHS does
not explain what the definition of "is" is, so some appeal to common usage
seems appropriate :> ). I believe that "system administrator" could be
read as a synonym for "person with root privileges", although this is just a
quick suggestion. As such, perhaps we could agree that user == !(system
administrator) thus, a user is someone without root privileges. This is by
no means set in stone, of course, but I contend that the confusion does not
extend to being totally ambiguous. If necessary, I can bring this question
to Rusty as well, although the guidance that he previously provided[1] would
seem to indicate that for the purposes of traceroute anyways, he considers
it to be a user tool for his definition of "user".
But this is a good point, and something that I think should be addressed
in the FHS itself. If you are not satisfied by the above, I am willing to
bother Rusty for a working definition of "user" and "system administrator."
Please note that Debian Policy suggests that we contact the editor of the
FHS for clarification[2], so I believe his decisions in terms of clarifying
the intent of FHS are authoritative for Debian Policy as it relates to the
FHS.
I also note that Debian Policy suggests asking debian-devel as well as
the FHS editor for "specific questions about following the standard,"[2] but
my interpretation of this sentence is that implementation questions could be
asked of debian-devel or the FHS editor(s), while the *intent* of the FHS
remains the purview of the FHS editor(s). Of course, the intent of the FHS
should inform the implementation, so maybe debian-devel is only relevant in
the case that the FHS does not address an application at all (such as the
location of a CVS repository). This is a weak point in my argument, and I'd
welcome alternate arguments that Debian Policy intends to say that
debian-devel can override the specific directives of the FHS, even in the
face of a clarification of intent by the editor. That discussion should
probably be moved to -policy (as should most of this), which I intend to do
if it becomes evident that the only viable solution is to modify Debian
Policy. (I do not we are at that stage yet, because the options of making
symlinks or moving the packages are not yet ruled out. I am optimistic that
this discussion may effect such change, especially in the face of the
clarification from the FHS co-editor, Rusty.)
> at the related entry for /sbin it is even contratctory to itself if you
> interpret it strictly. It lists programs that are required in /sbin but
> for any of those programs may be used as an user and so are not allowed in
> /sbin. E.g. could a system administrator allow his users to execute mkfs
> on /dev/fdX so they can format floppy disks, so mkfs.XXX are user tools
> according to fhs!
This is true, but I read this part of the FHS as specifying exceptions
to the definition of the directory, in addition to particular requirements.
Thus, while the text (of FHS v2.1, section 3.10[3]) says,
Deciding what things go into "sbin" directories is simple: If a
normal (not a system administrator) user will ever run it directly,
then it should be placed in one of the "bin" directories. [...]
in my reading, this is overridden by the list of "Required files for /sbin",
where they conflict. This is not clearly contradictory, although it does
not resolve the question of intent, as this is just my interpretation.
As I alluded to earlier[4], I do not believe that the mere presence of a
contradiction in a document merits ignoring the document in toto, so the
above argument is not convincing to me. I am especially skeptical of such a
decision if a clarification has been issued. Please note that I am not
accusing you of advocating that we should ignore the FHS, but that is one
argument that I think is being made[5], and your statement might be
interpreted as being in sympathy of that. I do not mean to attribute that
point of view to you.
> Back to traceroute. You will definitely need some system (or better
> network) administrator capabilities to interpret the output of traceroute.
>
> This does not hold for ping as with ping you do not necessarily have to
> understand its output to get the wanted information. I.e if you want to
> know if a host is available you simply have to look if ping gives you any
> ordinary output at all.
I suppose you could argue that (although I do not find the argument
compelling). However, I think it is irrelevant according to Debian Policy
because that is not a criteria of the FHS. If we want to apply our own
criteria in the place of (or in addition to) the FHS, I think that must be
specified in Debian Policy. As it is, it is my understanding that we have
agreed to adhere to the FHS (in compatibility mode) as it is written.
Either we must live up to that statement in Policy[6], or we should modify
the statement.
Rene
References:
[1] As reported in <http://lists.debian.org/debian-devel-0106/msg01005.html>
[2] <http://www.debian.org/doc/debian-policy/ch-opersys.html>
[3] <http://www.debian.org/doc/packaging-manuals/fhs/fhs-3.10.html>
[4] <http://lists.debian.org/debian-devel-0106/msg00976.html>
[5] <http://lists.debian.org/debian-devel-0106/msg00961.html>, seemingly, as
alluded to in <http://lists.debian.org/debian-devel-0106/msg00973.html>
[6] <http://www.debian.org/doc/debian-policy/ch-opersys.html> and
<http://bugs.debian.org/98291>, of course. What else did you think? :>
--
+--- (Rene Weber is <rene_autoreply@elvenlord.com>) ---+
| Put no trust in cryptic comments. |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
Reply to: