On Wed, 3 Dec 2008 16:51:34 -0800 Steve Langasek <[EMAIL PROTECTED]> wrote:
> > I completely disagree. It's a welcome benefit if packages of
> > inferior quality are prevented from entering the archive in the
> > first place imo. If you want to test packages not yet ready for
> > debian
>
> The fallacy here is to assume that lintian cleanliness is strongly
> correlated with high package quality. It isn't. There are certain
> lintian *errors* that are almost certain indicators of *poor* package
> quality, but this is not proof of the converse.
Absolutely true - though lintian does an excellent job, it does not
claim to be the final arbiter of quality, merely a tool to assist in
raising the quality of packages. For a start, lintian always tests the
source package in isolation.
One problem in reviewing packages on debian-mentors is that
"lintian-clean" almost becomes the be all and end all of the quality
assessment - maintainers don't expect to have to fix anything that
lintian does not pick up.
Package quality has to be about a whole lot more than just
lintian-clean.
Simplest example - lintian cannot test if the program actually does
anything. A patch that inadvertently causes the program to crash or
just skip large parts of the codebase will not be picked up. Other
examples include pbuilder tests or any test that has to test the new
package against existing packages.
lintian would need a whole new class of checks where a consensus has
been reached that these errors (and these alone) are rigorously
indicative of poor package quality and that any incidence of these
warrants an automatic REJECT. To implement this, it would probably be
better if tools that actually run lintian as part of the build (debuild,
pdebuild some of the VCS-buildpackage tools) would check the lintian
result for these errors and actually fail the build if they occur
(Emdebian does this already). Lintian would also need to disallow
overrides for such errors.
I'm not at all sure how many checks would gain this level of certainty.
Some that might qualify (only a cursory glance, a full review would
probably pick others):
arch-dependent-file-in-usr-share {2 packages}
binary-in-etc
file-in-etc-not-marked-as-conffile {7 packages}
package-contains-ancient-file
file-directly-in-usr-share
file-in-usr-local {1 package}
dir-in-usr-local
executable-is-not-world-readable {2 packages}
special-file {1 package}
symlink-has-double-slash
file-directly-in-usr-share-doc
http://lintian.debian.org/tags/
Hmmm, maybe not.
Before we implement such a REJECT policy, it's probably a good idea to:
a) RELEASE LENNY!!!!
b) get a consensus on which lintian errors are always unacceptable in
all packages
c) fix packages that already contain such errors (with NMU's if
necessary)
d) fix as many other lintian errors as possible throughout the archive.
(Quite a lot of lintian errors - some that I would consider quite
serious - affect several hundred packages.)
If we are going to make "lintian quality" such a banner for NEW,
shouldn't we imrpove the packages we already have in the archive first?
(after releasing Lenny, of course).
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpz4C8qVs9Vv.pgp
Description: PGP signature
