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.
