On Sat, Apr 14, 2001 at 12:22:03PM -0400, Sam Hartman wrote:
> >>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
> Anthony> Sure. *Everything* in policy is just a guideline, and
> Anthony> there can always be special cases. That's why we have
> Anthony> maintainers with good judgement.
> No, actually, I don't believe the guidelines that are MUST should be
> up to the maintainer's judgement.
*shrug* Believe what you want, but you're wrong.
Uh.
Okay, since when is:
Errors which occur during the execution of an installation script must
be checked and the installation must not continue after an error.
a must? It used to be, before must/should/may was introduced, but when
it was introduced it was specifically changed to a should. See bug 64437.
I can't see any mention in the changelog of this being changed back, and
I couldn't see any mention of it greping through the list archives. What's
going on?
Okay, a real example is:
To realize a smooth migration to
`/usr/share/doc/<package>', each package must maintain a symlink
`/usr/doc/<package>' that points to the new location of its
documentation in `/usr/share/doc/<package>'[1]. The symlink must be
created when the package is installed; it cannot be contained in the
package itself due to problems with `dpkg'.
In rare cases, specifically when a package has never been available when
with files in /usr/doc, it's quite reasonable to include the symlink in the
package itself. It's generally not worth the hassle, since most people will
use debhelper and have it done for them, but it's entirely possible, and
if the maintainer has good reasons for it, I'm not going to worry about it
or remove his/her packages.
Another example is the current bug about non-shared libs. There are
a few cases (including the current one) where policy is just plain
inappropriate. Those packages have good reasons for not shipping shared
libraries, so there's no way I'm going to remove them just because policy
only covers the vast majority of packages, and not the few special cases.
Relying on people's good judgement is much more productive and sensible than
trying to explicitly cover every case precisely correctly in a document, or
punishing maintainers who find themselves in corner cases.
> I don't believe it's ever
> appropriate for me as a maintainer to say that I want to violate the
> guidelines in section 2.1 regarding package copyright. Yes, I would
> reach this conclusion every time I considered violating the guideline
> and applied common sense. However, I believe it is likely the
> consensus of this list that no one should ever violate these
> guidelines.
Only because there aren't any good reasons to do so.
Of course I could be wrong: maybe there are good reasons to do so,
and I just can't think of any. If someone else does, well, good on 'em.
> My intent in this paragraph is simply to establish that
> there exists a class of guideline that a maintainer does not have the
> freedom to violate and that we can agree ahead of time on at least one
> member of this class.
Sorry, but we're not going to agree on that. The maintainer can do
whatever they want; if they don't have good reasons for doing what they've
done, then that's a bug. If it's something particularly problematic,
like a missing copyright, or violting the DFSG, it'll be a RC bug and
the package will be removed. But not if it's policy that's in the wrong.
> Anthony> If you don't have any common sense or good judgement,
> Anthony> please go away.
> I believe I do, so I choose not to go away at this point.
Good for you!
> Agreed, but not relevant to my point. I asserted that it was not
> clear to me that policy acknowledged that class of guidelines, not
> that I as a maintainer don't acknowledge that class of guidelines.
> There are people who go away reading the definition of should in
> policy and believing that the only difference between should and must
> is the typical severity of the bug.
Well, that's good, because that's *exactly* what I intended when I
proposed it.
> I think this is a bug in
> policy--and just because I as a maintainer can understand what was
> really meant doesn't mean that cleaning up the wording isn't a good
> idea.
What was "really meant", huh?
> I'm going to try and file a good bug report regardless of the severity
> of the bug. I think though that this points out one of our major
> disagreements : I believe that violating a SHOULD guideline (in the
> RFC sense) without good reason ought to be an RC issue, just as
> violating a must guideline.
This is why I'm losing all faith in -policy being a competent arbiter of
RCness.
There's no good reason not to have a manpage for a binary. "I'm too lazy to
write one" isn't a good reaosn, for reference. That doesn't mean I'm going
to remove packages that don't have them.
(Geez, when you setup strawmen for people they're not meant to say
"Yes! Yes! That's exactly my position!")
> Anthony> You're all insane, btw.
> By insane, I assume roughly that you're saying we're being
> unreasonable
No, I just mean that that's the only possible explanation of people who
don't agree with me when I'm so clearly and evidently in the right.
Cheers,
a "it's all so simple, really" j
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpmIqaYMFJA4.pgp
Description: PGP signature