Re: lintian -- detecting hundrets of bugs within seconds...
> On 29 Jan 1998, Manoj Srivastava wrote:
> > john> I wrote:
> > >> Perhaps because they are bugs in lintian? I think lintian is a
> > >> good idea, but we have to have a way to override it. Surely you
> > >> don't expect it to be infallible!
> > john> Joost writes:
> > >> Fortunately, somebody who is capable of writing something like
> > >> lintian, is also capable of predicting that lintian will never be
> > >> perfect. That must be why, already in the initial announcement, the
> > >> authors said that everything would be overridable.
> > john> I know that. It appeared to me that Manoj was objecting to that
> > john> very thing.
OK, sorry. I misread Manoj's statement.
> That's the dilemma: one the one hand you want an easy way to override
> lintian's error messages (if lintian should have a bug and there is no
> easy way to override it, people will start to hate lintian--which would be
> worse than having no lintian) and on the other hand you don't want
> maintainers to override lintian's error messages just to get the package
> installed in the archive but w/o checking/fixing possible bugs.
> That's why we considered the following solution: The lintian-overrides
> would have to be included in the corresponding changelog file entry, for
But that means that the tempcap package would have to have an lintian
entry in it's .changes file every time it gets uploaded? I strongly
object to this! I think it's _very_ good that there is/willbe a checker
that checks "normal" packages for conformance with the policy, but I
do think that it should be possible for non-normal packages to differ
sensibly with the policy. For example, policy for libraries is written
with 'normal' libraries in mind. For fakeroot I probably also break
current/future policy, as fakeroot comes with a shared library, but
doesn't have the major version number in the package name. Now for
nearly every library this is a very bad idea, but there's really
nothing that would suggest to me that having major numbers in fakeroot's
name is good. So I think it would be good if lintian checked for
"major version number part of package name", and reported errors for
that. But I don't want to have to set a overrule in my .changes file
every I upload fakeroot.
Also I'm not sure we should allow/advice maintainers to upload packages
with lintian overrides in them, just because the new upload contains
(signifficantly) less bugs than the old one. Gcc also doesn't say
"OK, I cannot find this #include file, but at least this time there's
only one misspelled #include file, so let's generate a .o anyway",
and dpkg-buildpackage also stricktly refuses to build any package that
it finds errors in (and dpkg-* also does sanity checks, like lintian).
So, in short: I think overrides (even easy ones) are essential, but
I think they only should be used when the maintainer thinks his package
is so special that some part of debian-policy doesn't apply to his
joost witteveen, email@example.com
The upstream maintainer is allowed to do things different
than Debian, but only if he has good reasons to do so.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .