Bug#54968: marked as done ([OLD PROPOSAL] Lintian, archive maintenance and and policy)
Your message dated Wed, 13 Jun 2001 13:16:54 -0500 (CDT)
with message-id <20010613181654.5FE474715@speedy.private>
and subject line Bug #54968: Lintian, archive maintenance and and policy
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
(administrator, Debian Bugs database)
Received: (at submit) by bugs.debian.org; 13 Jan 2000 07:32:14 +0000
Received: (qmail 17628 invoked from network); 13 Jan 2000 07:32:13 -0000
Received: from chiark.greenend.org.uk (firstname.lastname@example.org)
by master.debian.org with SMTP; 13 Jan 2000 07:32:13 -0000
Received: from 387d7f55.607fd.1f1e.0.bsmtp.davenant.greenend.org.uk by chiark.greenend.org.uk with local-bsmtp (Exim 2.05 #1)
id 128ejr-00025D-00 (Debian); Thu, 13 Jan 2000 07:32:11 +0000
Received: from ian by davenant.greenend.org.uk with local (Exim 2.125 #2)
id 128YA1-0004oP-00 (Debian); Thu, 13 Jan 2000 00:30:45 +0000
From: Ian Jackson <email@example.com>
Content-Type: text/plain; charset=us-ascii
Date: Thu, 13 Jan 2000 00:30:45 +0000 (GMT)
Subject: Lintian, archive maintenance and and policy
X-Mailer: VM 6.62 under Emacs 19.34.1
Package: debian-policy, lintian, ftp.debian.org
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
* 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
* 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
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
#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.
Received: (at 54968-done) by bugs.debian.org; 13 Jun 2001 18:17:00 +0000
>From firstname.lastname@example.org Wed Jun 13 13:16:59 2001
Received: from 18.104.22.168.adsl.hal-pc.org (speedy.private) [::ffff:22.214.171.124]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 15AFCN-0003V2-00; Wed, 13 Jun 2001 13:16:59 -0500
Received: by speedy.private (Postfix, from userid 1000)
id 5FE474715; Wed, 13 Jun 2001 13:16:54 -0500 (CDT)
Subject: Re: Bug #54968: Lintian, archive maintenance and and policy
Date: Wed, 13 Jun 2001 13:16:54 -0500 (CDT)
From: email@example.com (Steve Greenland)
This note is being sent as part of a project to clean out old (> 1yr)
debian-policy proposals. If you disagree with action below please
respond to firstname.lastname@example.org, not to me, so that the discussion may
be carried out publically in debian-policy. Feel free to re-open the
bug while it's being discussed -- I'm not trying to force any
particular disposition, just taking my best shot at resolving dead
Bug #54968: Lintian, archive maintenance and and policy
Summary: Proposal that since (a) dinstall was auto-rejecting packages
with lintian errors, there (b) should be a way for the maintainer to
override. Responders pointed out that (a) wasn't true and that (b)
already existed, although it was perhaps under-documented. Lot's of
followups related to specific situations.
Discussion: Since the premises of the proposal wasn't true, and the
solution already exists, this proposal seems irrelevent.