Bug#54968: Lintian, archive maintenance and and policy
Ian, (IANADD(Y)), but part of me wonders if this isn't the behavior we want;
most debian users have come to expect their debian-supplied packages to
behave a certain way. Allowing the packages to break that 'certain way' with
a one-line entry in the .changes file seems to be opening the floodgates.
I think I would be more welcoming if I saw an example or two of programs
that were kept out of the archives, along with the accompaning (sp?) errors
that did indeed look rather silly. One thought I have -- simple errors ought
to be simple fixes. Fundamental errors require fundamental fixes -- the
lintian exception list.
Perhaps an extension to this idea, along the lines of the package 'pool' --
allow the tools to decide what level of lintian errors they are willing to
install. One could have a lintian-pristine OS, one with limited errors, and
one that didn't care how messy things got.
I don't know if I prefer that or not. Hehehe.
$0.002. :)
Thanks Ian!
:)
On Thu, Jan 13, 2000 at 12:30:45AM +0000, Ian Jackson wrote:
> 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.
>
>
> --
> To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
Seth Arnold | http://www.willamette.edu/~sarnold/
Hate spam? See http://maps.vix.com/rbl/ for help
Hi! I'm a .signature virus! Copy me into
your ~/.signature to help me spread!
Reply to: