Bug#54968: Lintian, archive maintenance and and policy
Package: debian-policy,
I'm not sure quite what package to submit this under, but I think we
have a problem.
Current arrangements are that you can't upload new packages which have
lintian errors. I don't think this is correct, because packages which
have lintian errors might still be an asset to the distribution.
However, clearly we can't expect the FTP archive maintainers to
personally decide whether each error or bug is important enough to
prevent a package's inclusion. They need a procedural way to do this
(and the need for such a procedural check is how the `no lintian
errors' requirement got there in the first place).
Also, we can't expect the lintian maintainer (or the maintainer of
some other automatic checking software) to keep abreast of every
possible exception and/or possible bug in policy or lintian.
Certainly we shouldn't put the lintian maintainer on the critical path
for getting random packages included in the distribution.
So, let us step back and bit and see what we mean when we find that
lintian reports an error with a package. There are a number of
possibilities:
* The package is simply buggy. If the error is severe enough (eg, if
it is release-critical) then it should be rejected; otherwise it
should go through but we would like to know that a bug report had been
submitted.
* The package has some special quirk which means it has to do
something which lintian thinks is a bug. I understand that lintian
has an exception list for this case, so this is a bug in the lintian
exception list. Again, we'd like to know that the maintainer knew
about it and a bug had been submitted.
* The package maintainer disagrees with policy and is pursuing the
matter through the policy group, or appealing to the technical
committee, or something. In this case probably the package should be
accepted in the meantime. The maintainer has presumably weighed up
the consequences of installing the package despite its policy
violation. But, we would like to know that the maintainer was aware
of the policy violation, and that a bug was open against policy.
There are probably a few more rare cases, but I think my proposed
exception mechanism will handle them all.
You'll notice that the common thread running through these cases is
that it's usually OK to include the package if the maintainer knew
about the problem and a bug is open. So, I propose that we give the
maintainer a way of saying `I know about this and it's a filed as a
bug'.
This would take the form of a `Known-Problems' field in the .changes
file. Initially this would be an X-C-Known-Problems so that old
versions of dpkg-dev can build packages; the archive script would
understand both. The syntax would be something like
X-C-Known-Problems:
#3923 lintian E: binary-without-manpage ls
#4000 lintian E: postinst-does-not-set-usr-doc-link
(I forget the exact format of Lintian error messages.) The idea is
that the archive maintenance software knows that the maintainer
expects that lintian error, and quotes the relevant BTS number. The
string `lintian' is included in case we develop any new checking
software. The archive maintenance script would know that a lintian
`E:' is an error which should correspond to an open bug of at least
severity normal and would check this.
We also need a way for lintian to distinguish errors which should
correspond to normal severity bugs, and which correspond to
release-critical bugs. The latter should be rare. I'd suggest that a
new C: prefix be defined for critical errors, which the archive
maintenance script would check corresponded to a bug which was
important or more severe.
Ian.
Reply to: