Hello, On Wed, Jun 27, 2001 at 03:18:23PM +1000, Anthony Towns wrote: > And here we go again. Policy is *not* a set of hard and fast rules for > building packages. It has bugs, it's missing exceptions that should be > there, it doesn't cover everything that should be covered, it suggests > suboptimal solutions, it's self contradictory, it's all sorts of bad > things.
Granted. Mind you, this was not specified in Policy itself, so an
outside observer could very well read Policy and not take this meaning from
it at all. I think your proposal #102213 goes a long way to making this
clear, which is a very good thing.
> That's what it is. Right now. It's what it's always been, too. That's
> a fact of life. It's true for "may" clauses, "should" clauses, and even
> "must" clauses. Policy isn't perfect.
Certainly it is not perfect, but I don't think it follows that we should
refrain from correcting it when the corrections are necessary and possible.
I still fail to see what is so anathematic about a footnote to the effect
that (for example) Policy recognizes the FHS' rules regarding sbin
directories as flawed.
> Reread the above a couple of times 'til it sinks in.
Perhaps if I had had the chance to read anything official that expresses
anything like the above, it would have sunk in the first time. As it is,
this is the first time I have read any kind of pronouncement like this (if I
missed such a statement somewhere where I should have seen it, I apologize).
If the rest of -policy agrees (which I can infer from the lack of argument),
then I am happy to accept it.
> There are two reactions to the above that can be taken; they're not
> mutually exclusive.
>
> One is to accept the policy is imperfect, and use some intelligence and
> discretion to build good packages anyway. While it's not perfect it is
> generally correct, and it's entirely good enough to rely on in general.
> Similarly, while maintainers aren't perfect, they generally know what
> they're doing with their packages, and when they don't, are generally able
> to act sensibly when given advice. That reaction's what this proposal is
> about, and what we've historically had: policy is a basis for helping
> maintainers maintain good quality packages. It's not a law that needs
> to be policed.
Great. This is a pragmatic approach that I heartily endorse. However,
I think that the existence of a Policy document is commonly construed as
authoritative (which is encouraged by the first sentence of section 1.1,
stating that it describes "policy requirements"), so a statement to the
effect that this Policy is a work in progress and should not be relied on as
law seems necessary to me. (This is pretty close to the effect of your
proposal, I note with approval.)
> The other approach is to consider all these imperfections as bugs, and
> keep working on policy until they're all fixed, and we can have perfect
> certainty whether a package is bug-free just by running lintian over it.
This is a decent goal to pursue, but I certainly don't mean to give the
impression that I feel this is the only way to have a Policy. My point was
based on reading a Policy that did not admit that it has flaws. If Policy
had (even implicitly) admitted that it is flawed and that there is
maintainer discretion in following its edicts, then I would not have been so
concerned that we were betraying Policy.
> Personally the latter doesn't seem achievable in any meaninful way or
> particularly worthwhile; and doesn't seem achievable in any way in the
> short term.
I agree that it is probably not achievable (especially in the short
term), and as an absolute probably does not hold much worth. However, as a
vague goal that does not have to be completely realized, I think it does
have value. Is it not worthwhile to try and resolve (for example) self
contradictions?
I feel that (without contradicting my text above) we should still
attempt to reconcile Policy and practice so that an "escape clause" is
rarely invoked. That would make Policy less haphazard and more complete,
two goals that I think are worthwhile. Would you consider a footnote to the
FHS statement explicitly stating an exception for sbin, since that seems to
be a large hole (and would have the advantage of probably being able to
forestall some of the traceroute argument next time it returns)?
Rene
--
+--- (Rene Weber is <[EMAIL PROTECTED]>) ---+
| "Magazines all too frequently lead to books and should be regarded by |
| the prudent as the heavy petting of literature." -- Fran Lebowitz |
+--- E-Mail Policy & web page: <http://satori.home.dhs.org/~rweber/> ---+
pgpDTSja6rYLK.pgp
Description: PGP signature
