Re: sponsor rules
On 17 Jul 2001, Bob Hilliard wrote:
> Josip Rodin <joy@cibalia.gkvk.hr> writes:
>
> > On Mon, Jul 16, 2001 at 06:14:33PM -0700, Ian Eure wrote:
> > > it's really not too hard to run 'lintian -i foo.deb' and 'dpkg -i
> > > foo.deb'. perhaps katie could be modified to reject uploaded packages that
> > > aren't lintian-clean.
> >
> > This has been proposed before, however, lintian is quite imperfect so it
> > would probably give too many false matches.
> Policy could be modified to require that the maintainer include
> in the package a justification for any lintian errors (not warnings).
> This could take the form of mew field in the source control file, or a
> specified file included in the package. katie could be modified to
> flag packages with lintian errors for manual installation by the
> ftp-masters.
It's already possible to suppress lintian errors using the
/usr/share/lintian/overrides/ method. The trouble is, this imposes quite a
lot of work on maintainers everytime a lintian bug or misfeature leads to a
false positive, and it also encourages a mode of operation ("lintian's
complaining again; better shut it up so we can get this installed to the
archive") that can make it more difficult to track bugs in the long term.
One option that seems promising to me, OTOH, may be for the installers to
handle lintian similarly to the way RC bugs are handled when moving packages
into testing: when a new version of a package arrives in incoming, run lintian
against the old and new package (so that we get output from the same version
of lintian for both), and if the new package doesn't have /more/ lintian
errors than the version currently in the archive, it's safe to install the
package (modulo the outcome of other existing checks). Of course,
implementing this would be ftp masters' prerogative; if they're interested,
I'm not averse to coding up such a check.
Steve Langasek
postmodern programmer
Reply to: