Re: traceroute in /usr/bin, not /usr/sbin
Hello,
On Sun, Jun 17, 2001 at 08:04:25PM +1000, Craig Sanders wrote:
> On Sat, Jun 16, 2001 at 04:58:46PM -0400, Rene Weber wrote:
> > I don't think Debian wants to say that we will embrace standards
> > except where we disagree and in those cases we will silently ignore
> > what the standard says.
[Craig wrote]
> debian has *always* said and done that, and always will.
>
> debian is a real world practice, not ivory tower theory.
Great, but I don't think it is appropriate to *silently* ignore what the
standard says. I deliberately used the term "embrace" in the twice-quoted
section above. Please don't make me complete the thought.
> it's the job of any implementation team to interpret the standards and
> do something practical and useful with them. that will always mean
> tossing out or ignoring the stupid or impractical bits and reconciling
> conflicts between different standards, as well as conflicts between any
> standard and existing code/practice.
>
> slavishly following a policy document even where it is wrong or broken
> is the work of foolish automatons, not creative hackers.
>
> free software and the net have been built on rough consesus and working
> code.
>
> FHS is the "rough consensus", Debian is the "working code".
>
> there never will be a 100% match between the theory and the practice.
> it's not even an admirable goal to strive for 100% because that falsely
> pre-supposes that the theory is perfect and can not benefit at all from
> exposure to real world conditions. it should be obvious how likely that is.
Ok, I appreciate the sentiment of what you are saying here, and I even
agree with most of it. My question is if it is general opinion that we are
not being deceptive by claiming that we "must" be FHS compatible, and then
deliberately (and advisedly) breaking FHS compatibility outside of
extraordinary circumstances.
Perhaps it is implied in Policy that by saying that we "must" be FHS
compatible, we mean "unless working code dictates" (by that I mean real
world practice; I have already pointed out[1] that if following the FHS means
breakage for the package in question then it is free to break policy in that
regard). My understanding is that that is not the meaning of "must",
although it could be implied from "should". This understanding is bolstered
by the proposal[2] which suggested adding such a clause to policy for FHS
compliance (note: compliance, not compatibility), but decided that the fact
that FHS compliance was already a "should" rendered that specification
unnecessary.
If I am wrong, and general opinion is that "must" means "unless real
world practice differs," then I am perfectly happy to let the matter drop,
as we will no longer be lying to our users.
Rene, who thinks an easy solution for the moment is to change the FHS
directive in Policy[3] to read "should" be FHS compatible, instead of
"must". That will not stop this thread from returning however.
References:
[1] In <http://lists.debian.org/debian-devel-0106/msg00938.html>, for
example.
[2] <http://bugs.debian.org/98291>
[3] <http://www.debian.org/doc/debian-policy/ch-opersys.html> as modified by
<http://bugs.debian.org/98291>
--
+--- (Rene Weber is <rene_autoreply@elvenlord.com>) ---+
| Big Brother no longer works exclusively for the government. These |
| days, he freelances in the corporate sector. |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
Reply to: