Re: Bug mass filling
(Yes, I'm on vacation, and really am still on vacation, but I had a brief
check-in moment and happened to see this thread. Note that I probably
won't see responses, unless I get to them tomorrow night, until the
beginning of November.)
Aurelien Jarno <aurelien@aurel32.net> writes:
> I have just run lintian on all the archive (amd64) for both binaries and
> sources, and the results are a bit scary. It looks like a lot of
> maintainers are uploading their packages, and don't really care with the
> policy.
> Maybe some errors (E:) of lintian could be changed to critical (C:) and
> uploads containing such critical errors be refused by dak? What do you
> think?
Please note that lintian considers *any* violation of policy, even things
that in practice won't cause problems, to be worthy of E:. In this
particular case:
> Among all of the bugs reported by lintian, one concerns a lot of
> packages, the presence of the clean, binary, binary-arch, binary-indep
> and build targets. This is required by both the section 4.9 of the
> policy and the Etch release standards [1]. Here is the list of affected
> packages. What to do with them?
what's generally going on is that the package builds only arch-dependent
or arch-independent packages and therefore the missing target is a no-op.
Due to the way that the autobuilders work and the normal package building
tools work, in practice this will almost never be noticed. However,
policy *does* require that the targets exist, so lintian dutifully
diagnoses the problem.
Another common lintian error that doesn't cause problems in practice (now)
is that lintian intentionally does not take transitive dependencies into
account when checking package dependencies and build dependencies. This
means that if, for instance, your debian/rules calls a program from
po-debconf, lintian will complain if you don't build-depend on po-debconf,
even if you're already build-depending on debhelper which in turn
build-depends on po-debconf. This is because reliance on transitive
dependencies in general creates dormant RC bugs. If for some reason (and
I realize that this is unlikely, but one can construct reasons why it
might happen) debhelper drops or downgrades its dependency on po-debconf,
all those packages that just relied on debhelper to pull in po-debconf
immediately are RC-buggy. Adding an explicit dependency is easy and
avoids this problem.
(If, however, a package is *defined* as being equivalent to depending on
another package, I'm willing to teach lintian about those special cases,
the same as how it handles virtual packages like c-shell now.)
I've put a lot of work into lintian over the past six months focused
specifically on eliminating false positives, so I'd love it if people
would run the unstable lintian regularly on packages and report as bugs
any false positives that don't look unavoidable. (lintian -i will often
give you clues as to whether the false positive is unavoidable; if lintian
-i specifically recommends an override, that generally means that the
lintian maintainers believe it infeasible to entirely avoid false
positives there.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: