On Fri, Apr 13, 2001 at 12:49:40AM +0100, Julian Gilbey wrote:
> On Fri, Apr 13, 2001 at 02:22:54AM +1000, Anthony Towns wrote:
> > So we no longer accept uploads of packages that don't have manpages for
> > all their binaries?
> OK, let's take this example then. At the moment it's only a "should".
> Why can't we say that, from now on, we will not accept uploads which
> fail this?
> My suggestion is: change "should" to "must" in policy, and give
> packages some time to migrate (eg., one year) before starting to do
> NMUs.
Suppose we do. First, what benefit does this provide to the user who
gets a copy of the new woody release in, say, six months on CD. Can they
rely on every binary having a manpage? No, because it's not a real "must".
Second, what happens to, say, security NMUs of packages without manpages?
Do they get rejected out of hand, because of RC bugs? Or do the security
team have to write manpages as well as do the fix and release advisories?
What about NMUs to fix real RC bugs, like the app-defaults thing? Do
they have to write manpages as well as fix the bugs as well? What about
maintainers who just want to fix normal bugs promptly? Do I have to, say,
write manpages for ping6 and traceroute6 and tracepath and tracepath6
when I make an upload of iputils.dsc to set its Maintainer: to debian-qa?
This sort of requirement seems to erect more barriers in the way of
improving a package's quality, without even offering any assurance that
the overall quality of packages will particularly improve.
"In order to fix the typo in this bug, you must read the current policy
document, add a manpage, move to /usr/share/doc, add a symlink from
/usr/doc, update your description, contact the translation team to make
sure your package's description and manpages are translated into French,
German and Japanese, register all your documents with doc-base, register
your programs with update-menus, ensure lintian doesn't register any
errors, and then you may upload".
You can't dictate that maintainers will be motivated to fix their packages
no matter how much you might want them to. It's a mistake to try.
> This is probably a highly effective way of doing away with
> "undocumented.7" and ensuring that all binaries have proper manpages
> without imposing the burden of either large scale NMUs or pulling lots
> of packages.
It seems more like a highly effective way to make maintainers get sick of
bothering, and leave lots of packages unorphaned but also unmaintained,
to me.
If you want a truly effective way of doing away with undocumented.7,
get people to right manpages and submit them to the BTS.
Someone has to do the work. The maintainer's already indicated s/he
isn't that interested in writing manpages by the very fact that s/he
hasn't written any. If you want manpages as badly as you seem to: *you*
write them.
Recently there's been a flamewar in a newsgroup I like to read about
welfare and government mandated minimum standards of living. In it, one
of the participants (who was against it) accused another (who was for,
obviously) of being in it for the power, the argument was something
like whoever is in control of ensuring a minimum standard of living
gets to control both the poor (by being their major source of income)
and the rich (by controlling most of their income).
There seems to be something similar going on here: policy wonks grabing
power over maintainers by arbitrarily deciding whether their packages
are acceptable or not, and using that power to satisfy their own goals
whether anyone else likes it or not.
Sure, they're doing it for their own good, but that doesn't make it right.
Maybe the entire idea of "MUST" is wrong, and -policy can't be trusted
with fairly and reasonably deciding what's acceptable for release and
what's not.
> > > - we don't file RC bugs on new requirements until we decide that it
> > > is necessary and that we are realistically able to fix any packages
> > > with the issue outstanding in a reasonable length of time
> > Indeed. We can do this right now by making them recommendations (should)
> > instead of requirements (must), and update them later if it's appropriate.
> So one day you have a minor bug report against your package, the next
> day it becomes an RC bug report with the threat of your package being
> pulled.
"the next day" ?
One day you have a minor bug report against your package.
Three months later, while every other maintainer except you has gone and
done stuff about it, and a policy proposal listing the packages still
violating the guideline (yours and a handful of others), and saying why
consistency in this area is crucially important, passes, the bug gets
upgraded to serious, and someone offers to NMU for you.
> > I have another suggestion. Let's get rid of the "Standards-Version" field
> > in debian/control and insist all packages must match current policy.
> No and yes.
> I think the Standards-Version is good when we look at a package to
> determine what the state of policy was when it was last uploaded and
> what might need to be modified to bring it up to date. So I wouldn't
> want to lose that information.
You'll note that phrase: "might need to be modified to bring it up to date".
Skipping down, we see:
> This is exactly the situation at present. In sid/main, there are
> Standards-Versions ranging from 2.1.0 through to 3.5.8 (which is quite
> an achievement, really, given current version is only 3.5.2!). Out of
> approximately 4000 packages, there are close to 300 source packages
> with version < 3.0.0 and over 1000 (that's a quarter) with version
> less than 3.1.0.
Skipping further down, you then use this as an indiciation that no one listens
to policy, and that therefore harsher measures must be undertaken.
But Standards-Versions *aren't* an indication that a package *does*
need to be modified to match policy. They're just an indication that it
might be worth looking at them.
And that's the trouble with Standards-Versions: they lead people to think
they're more than they are, and then go off on strange tangents about how
no one complies with policy anymore, and how much kids of today suck.
There're (or ought to be) better sources of information about whether
packages comply with policy. The archive wide lintian runs used to be
a much more accurate and precise source. Scanning through the Contents
file is still a good way of checking many policy guidelines. For example,
FHS compatibility was first added in 3.0.0.0, so I guess you'd assume
that a Standards-Version less than 3.0.0.0 would indicate that the
package doesn't use /usr/share/doc. You'd be wrong. A quick check [0]
(which would tend towards underestimating) lists 134 such packages, which
is around half of the 280 packages with standards versions < 3.0.0 in sid.
This group seems quite happy to both make poor assumptions about the
correctness of other packages (treating standards-version fields as
more canonical than they are; not wanting to bother checking which
packages would be affected by new MUSTs in policy), and if -policy
is holding itself to such a low standard concerning other packages,
it seems at best hypocritical to demand package maintainers adhere to
the significantly higher standard that's being proposed.
> I don't think that it's reasonable to demand that all packages in the
> archive are constantly updated to match current policy, with two
> provisos:
> (2) No package should be more than [fill in appropriate time] old
> policy-wise, eg., require all packages to have Standards-Version
> >= 3.0.0 in woody
How about we just require them to meet all the MUSTs in current policy,
whether they've bothered to update the standards-version field or not?
Because we already do that, you'll note.
> > The fact that it's there seems to confuse people into thinking they
> > don't have to care about current policy. They do.
> But we don't make any attempt to enforce this. I am essentially
> proposing that we do.
http://bugs.debian.org/~wakkerma/bugs
We do enforce this. What we don't do is get in the way of package
maintainers trying to do their job when it doesn't matter.
And yes, you are proposing that we do.
> > [...]
> > If you want to make policy apply inconsistently to different packages,
> > well, I think that's just stupid, no matter how many times it's proposed.
> This is exactly the situation at present. In sid/main, there are
> Standards-Versions ranging from 2.1.0 through to 3.5.8 (which is quite
> an achievement, really, given current version is only 3.5.2!).
There are two such packages: lprng and ax25-tools; everything else has a
valid standards-version. Packages can be buggy, maintainers can make typos,
it's nothing to get excited about.
> Out of
> approximately 4000 packages, there are close to 300 source packages
> with version < 3.0.0 and over 1000 (that's a quarter) with version
> less than 3.1.0.
And, equally, old standards-versions are also nothing to get excited
about. Those numbers just plain aren't meaningful.
> > It'd help if you'd come up with a clear statement of what you'd like to
> > achieve, independent of your preferred solution. "Distinguishing between
> > guidelines that will get a package thrown out of the distribution and
> > guidelines that won't" is the problem MUST/SHOULD/MAY is designed to
> > solve, eg.
> Problems:
> (1) Many maintainers ignore policy changes and don't apply them to
> their packages. The above statistics give some indication of the
> extent of this problem.
No, they don't. Further, there are more helpful ways of solving this
problem than saying "get lost, we don't want your packages" to people
who aren't subscribed to this list. Restarting Joey Hess's "Policy
Proposals" sumamries and posting them regularly would help immensely,
I'd be willing to bet. Restarting the archive wide lintian laboratory
and using that to find things that need work, would probably help too.
Lintian alone is a pretty impressive measure at thwarting this.
> (2) We don't enforce policy dictates except by filing RC bugs at a
> very late stage in the process, once we've decided that the
> requirement should be an absolute.
This isn't a "problem", it's what you want to have happen prefaced by a
"not".
> (3) The above two points mean that it is hard to maintain a high
> quality of packages in any automated fashion, and that a large
> burden is put on a small number of developers who try to fix the
> problems thereby caused, for example the /usr/doc ->
> /usr/share/doc transition is still not complete.
It's impossible to maintain high quality packages in an automated fashion.
Other maintainers aren't robots, you know.
You'll note that the /usr/share/doc transition was meant to take until
now, btw, and that we've got 97% of the way there, pretty much exactly
as hoped. Without doing any coordinated NMUs at all yet.
> (4) It also means that we are often afraid to "do the right thing"
> and demand that packages satisfy certain criteria (all binaries
> to have manpages) because too many packages will then receive RC
> bugs, even though we should demand this of all packages and it
> really isn't an RC issue.
Demanding that all packages have manpages is not the "right thing". Again,
this is what you want to have happen, prefaced by a "not".
A restatement as a problem might be:
(4) Our distribution isn't very consistent in areas in which it could
be. For example, many of our packages don't have manpages for all
their binaries.
This can be addressed by, eg, getting interested volunteers to write
manpages and submit them to the package maintainers, which is exactly
what -qa is doing.
> (5) There is only language in policy for "this is an RC requirement"
> and "this is a requirement, but not RC". Both indicate bugs if
> there is a failure to comply. There is no language for: "except
> in unusual circumstances, you must do this", which would not
> necessarily indicate a bug for lack of compliance. (For example,
> the update-rc.d binary in file-rc need not have a manpage, as it
> depends on sysvinit which does. So maybe the manpage requirement
> really ought to be a "should" or needs to explicitly exclude this
> type of case.)
There is actually language for this, and it was given earlier in this very
thread.
Some examples from policy:
(with a weakened "should")
2.3.2:
[...] If one person maintains several packages
he/she should try to avoid having different forms of their name and
email address in different `Maintainer' fields.
2.3.8.1:
Packages should try to minimize the amount of prompting they need to
do, and they should ensure that the user will only ever be asked each
question once. This means that packages should try to use appropriate
shared configuration files (such as `/etc/papersize' and
`/etc/news/server'), and shared debconf variables rather than each
prompting for their own list of required pieces of information.
12.5:
Web Applications should try to avoid storing files in the Web
Document Root.
(with explicit exceptions)
2.3.5:
They should not use virtual
package names (except privately, amongst a cooperating group of
packages) unless they have been agreed upon and appear in the list of
virtual package names.
2.3.8:
If `update-alternatives' is not used,
then each package must use <Conflicts> to ensure that other packages
are de-installed. (In this case, it may be appropriate to specify a
conflict against earlier versions of something that previously did not
use `update-alternatives' - this is an exception to the usual rule
that this not allowed).
5.2:
This must undo any effects that the `build' and `binary' targets
may have had, except that it should leave alone any output files
created in the parent directory by a run of `binary'.
> Proposal:
It's not really a good idea to make proposals when you're not even
clear on the problems you're addressing.
> (b) The release manager decides upon a minimum acceptable
> Standards-Version for each release once (a) has been implemented.
And this goes *precisely* against what you've been saying earlier. The
minimum acceptable policy for packages to comply with at release is the
current version of policy. Even a difference of 0.0.0.1 is unacceptable.
*But*, packages won't be thrown out if their Standards-Version is out
of date, nor will they be thrown out if they only violate "shoulds" and
"mays", but not "musts".
I'm sure your heart's in the right place with all this, but it seems to
me your head is obsessed with the idea of abusing the almighty power of
policy's ability to declare things unreleasable to achieve your goals.
Is it still not clear why I'm objecting to this every single bloody time
it comes up? Is it not clear why it concerns me enough to write these
long turgid essays?
Adding a "MUST" is an *absolute last resort*.
If you do it too often, it'll just end up with the RM having to ignore
policy and go it alone again, just like we always had to when there
weren't any MUSTs or SHOULDs or important or serious severities. That's
not something I remotely want.
All this nonsense about "every package uploaded from now *MUST* have a
manpage because I said so" is far worse though.
Cheers,
aj
[0] zcat sid/main/source/Sources.gz |
awk '/^Package:/ {P=$2} /^Standards-Version:/ {print P, $2}' |
while read a b; do
if dpkg --compare-versions $b lt 3.0.0 &&
zgrep -q "^usr/share/doc.*/$a$" sid/Contents-i386.gz;
then
echo "$a $b has usr.share.doc";
fi;
done
--
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:
pgpQMY71auqby.pgp
Description: PGP signature