Re: lintian -- detecting hundrets of bugs within seconds...
> On 29 Jan 1998, Manoj Srivastava wrote:
>
> [snip]
> > 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
> example:
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
package.
--
joost witteveen, joostje@debian.org
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
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: