On Mon, Mar 26, 2001 at 09:35:36AM -0600, Steve Greenland wrote:
> On 25-Mar-01, 04:26 (CST), Anthony Towns <aj@azure.humbug.org.au> wrote:
> > If you create a "must" directive, then you've just created a reason to
> > have a number of extra RC bugs. Indeed, that's the only point of making
> > it a "must" instead of a "should".
> The point of making a "must" requirement is that the consequences of not
> following that requirment are sufficiently serious to justify removing
> a package that does not follow that requirement. The number of packages
> affected is largely irrelevant.
There are two reasons for removing packages that don't meet a policy
guidelines: either that it causes breakage that's considered RC anyway, or
that it causes an inconsistency that we don't like. The requirement that
games not be made setuid is an example of the first case, the requirement
that packages follow the FHS would be an example of the latter.
The number of packages affected definitely matters for the latter case:
if our mandate is mainly to document existing practice, then it seems a
bit inappropriate to insist upon a consistency that doesn't already exist.
> If I propose that "packages must not call 'rm -rf /' in their postinst
> script", we could all agree that it was a completely reasonable
> requirement no matter how many packages were affected.
Certainly. A proposal that "all packages must have docs in /usr/share/doc
not /usr/doc", OTOH, wouldn't be.
In the rm -rf / case, though, it's still relevant how many packages are
affected, if only in so far as to argue "but no one does this anyway,
and it's obviously stupid, what's the point of putting it in policy?".
> > If you're not going to bother filing the RC bugs, there's no reason
> > not to leave it as a "should". If you are going to file the RC bugs,
> > then someone's got to figure out which packages it applies to at some
> > point anyway.
> There's a huge difference between "you have to find all the affected
> packages" and "someone (probably many people) will have to find the
> affected packages".
In the end it comes down to me having to look through every such report
and make a decision on it though, so it's not that different. Better to
be informed before the fact than after, IMO. Better to have the proposers
work out what'll be affected for each of their respective proposals, than
me or Jordi have to work out what'll be affected by every proposal too.
> Are you also going to require that each person who suggests a
> modification to a proposal adjust the list appropriately? And who gets
> to keep up with checking the new packages every day?
Geez, I never suggested being dictatorial about it. If there's one or two
false negatives, it's not the end of the world.
But sure, if someone modifies the proposal they should try to understand
the effect of that modification, if the result's going to change whether
we're willing to release some package or not.
> > Because people don't seem to understand the point of the must/should
> > dichotomy.
> The must/should dichotomy is (or at least should be) based on the
> real consequences of not following a recommendation.
Indeed. People seem to think it's not relevant what happens if you don't
follow the recommendation though, because of course, if it's a must,
everyone will follow it, so clearly no packages are affected. [0]
That's mostly why I'd like to see lists of packages that currently don't
follow the recommendation, though: that way you can see some real examples
of exactly what happens if the guideline isn't followed, and you can see
how many packages will be pulled if you get too busy to do NMUs and the
maintainers don't get around to fixing it themselves.
> > Encouraging people to list the packages which'll have RC bugs filed
> > against them due to a proposal they're making doesn't seem particularly
> > drastic.
> Encouraging I could agree with, particularly when the check could be
> automated against the Packages file. But even an automated check against
> the maintainer scripts is not feasible for most people, and a lot of
> checks are not possible to automate.
A lot of checks are possible to automate: just have a look at lintian
some time. And there should be at least three people behind every policy
proposal anyway (a proposer and two seconds), at least *one* of whom out
to be able to give some sort of indication what packages will be affected.
Cheers,
aj
[0] http://lists.debian.org/debian-policy-0103/msg00088.html
http://lists.debian.org/debian-policy-0103/msg00312.html
--
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:
pgppBbvv5xKW2.pgp
Description: PGP signature