Re: lintian -- detecting hundrets of bugs within seconds...
Manoj Srivastava wrote:
> >>"Christian" == Christian Schwarz <schwarz@monet.m.isar.de> writes:
>
> Christian> 4. We'll provide any easy way to force dinstall to install
> Christian> a package ignoring any errors--without requiring the
> Christian> maintainer to reupload the packages. (Currently, dinstall
> Christian> moves rejected files into REJECTED/, I think. The
> Christian> maintainer can simply move them back into Incoming/ and add
> Christian> a file, say foo.lintian-override, to make lintian ignore a
> Christian> few error messages.)
>
> This I don't understand. Why are we making it easy to
> distribute packages with bugs? If the errors do not indicate bugs,
> why are they errors?
Lintian as invoked by dinstall will indeed be very conservative about
what it flags as an error. It should not be used by dinstall until we
can be confident that it only flags real problems. But even so, I can
think of a couple of reasons for such overrides.
- In some cases the errors that lintian detects will be far less
important than the errors that the package upload fixes. Security
uploads are the most visible example of this, but there are others.
- Suppose you take over an old package that has only a vague
resemblance to current policy. You start fixing it, but it takes a
while and you want to provide interim releases. Each upload still
contains policy errors, but is an improvement over what's already in
the archive.
- If lintian makes a mistake, it should be possible to get the
package upload through without waiting for lintian to be fixed.
- Even when it functions perfectly, lintian can do no more than
compare a package with current policy. (Well, it can also check for
common bugs.) The policy can be mistaken, or it can have unforeseen
effects when applied as zealously as an automated script will do. The
package termcap-compat is a good example of this. It is broken for
development, but for an excellent reason.
Richard Braakman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: