Re: Bug#102213: [PROPOSAL] Policy interpretation and exceptions
Hello all,
On Mon, Jun 25, 2001 at 10:49:48PM +1000, Anthony Towns wrote:
> I think we should emphasise compliance with the spirit of policy, in the
> cases where that might conflict with the letter. I think there's general
> agreement about this, but I'm not really sure.
I generally agree with this, but I think it is probably a better idea to
modify the letter of policy so that it no longer conflicts with the spirit
(possibly in addition to the specification of this kind of "escape clause"
as a catch-all). In particular, I am concerned that this part of policy
could be used to justify most any kind of policy violation, as there is no
specification of what kind of special case would warrant breaking policy.
This is not a fault of the policy proposal itself, as specifying such detail
is rather onerous, but I think it is a weakness of the "escape clause"
genre.
Having said that, it does resolve the ambiguity between policy and
practice by specifically allowing packages to break policy without an
outstanding reason (notwithstanding the "rare cases" clause, see below).
Whether -policy wants to encourage this kind of behaviour (that is, as
Anthony says, if there is general agreement about this) is up to everyone
here.
I do, however, have a few comments about the specific language of the
text. Sorry!
> So, for your perusal, here's a possible addition to policy's scope section:
>
> --- policy.sgml Fri Jun 1 19:40:16 2001
> +++ policy.sgml.discretion Mon Jun 25 22:47:48 2001
> @@ -157,6 +157,21 @@
> merely informative, and are not part of Debian policy itself.
> </p>
>
> + <p>
> + The guidelines in this manual are expected to be interpreted
> + intelligently, with a view to improving the technical quality
I'm not sure that "intelligently" adds anything useful to this text. If
anything, it seems to embody the possibility of denigrating any readers who
read policy with a literal mind set. I am sure that Anthony meant no such
belittling, so perhaps replacing "intelligently" with "loosely" or
"critically," or leaving it out entirely, would be more judicious (please
choose whichever fits more with the intent of the text, of course).
> + of the Debian distribution. Where a guideline in this manual
> + does not make sense for a particular package, or describes
> + an inadequate solution, the maintainer should discuss the
> + issue with other developers via the <tt>debian-devel</tt>
> + or <tt>debian-policy</tt> mailing lists, with a view to
> + finding a better solution, or correcting a flaw in policy.
> + In rare cases a package may be enough of a special case that
> + it should not follow a guideline and the exception would just
> + be confusing if listed in this manual itself. In those cases,
> + a comment to this effect should generally be included in the
I am unclear as to the import of "should generally" in this context. Is
this a further diminished form of "should" (but stronger than "may")? I
believe Debian would be better served by framing this as a "must" (after
all, if a package is breaking policy, it does not seem to be too much to ask
for it to document this), but I am willing to postpone any such arguments
until after woody's release in the interests of expediency.
> + package's <tt>README.Debian</tt> file.
> + </p>
>
> <p>
> In this manual, the words <em>must</em>, <em>should</em> and
I am also unsure that this is enough to lay the /usr/sbin matter to
rest (I am mentioning this in this mail based on the assumption that that
was the intent of this proposal. If that is not the case, this question
should probably be discussed outside of bug #102213). In that case, it is
not one or two packages that are breaking policy (thus, the "rare case"),
but a significant portion of the packages that currently have binaries in
/sbin[1], and probably /usr/sbin as well. Perhaps one could argue that the
"rare case" is our disagreement with the FHS on the criteria for placing
binaries in sbin directories, but in that case is it infeasible to codify
that in policy by saying something to the effect of "Packages must be FHS
compatible except in the case of sbin directories where the below policy
indicating what should go in sbin directories will override the FHS'
requirements"? This has the additional advantage of not leaving maintainers
in the dark as to what should replace the void left by the apparent
discarding of the FHS' rules for sbin directories.
I would welcome a reasoned argument based on that, or anything else that
will lay this to rest. (I also note that this proposal does not seem to be
sufficient to stop the precipitating argument from returning, as it is
debatable if the exception is fairly applied, so we are likely to see more
"traceroute belongs in /usr/bin" threads in future.)
Thanks for the effort!
Rene
References:
[1] As argued by Herbert Xu in
<http://lists.debian.org/debian-devel-0106/msg00878.html>, for example.
--
+--- (Rene Weber is <rene_autoreply@elvenlord.com>) ---+
| "Style. Beauty. Grace. That's what matters. If cats looked like |
| frogs we'd realize what nasty, cruel little bastards they are." |
| -- Terry Pratchett |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
Reply to: