Bug#54968: Lintian, archive maintenance and and policy
Hi,
I support this proposal in principle; the (relatively)
undocumented feature in lintian means some of the details need
changing a little, so I shall modify it a little.
> 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
This is correct.
> 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.
Also.
Here are reasons a package may have lintian errors, or other things
that may cause the ftp maintainers to reject it.
> * 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.
This point is particularly relevant to me at the moment - one of my
packages has been rejected twice, the second in the midst of a -policy
discussion where I am justifying the action which it is being rejected
on the grounds of (there is another error, as has been pointed out,
but it isn't RC).
> 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 is an important principle
> 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.
There should be some mechanism for pointing out other bugs that relate
to the package - probably having "maintainer" instead of lintian in
the above examples.
> 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.
I think also the principle of only rejecting uploads with RC bugs in
is important (ignoring the flamefests elsewhere about whether or not
you think maintainers should spend their lives dotting all the is and
t's or producing slightly buggy packages with whatever time they have)
- if it's not RC, then the package would be releasable, so has
contributed in a positive manner to Debian, so should not be rejected.
Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org
Reply to: