Bug#856857: lintian: potential improvements to empty-binary-package check

[Helmut Grohne <helmut@subdivi.de>]

Package: lintian
Version: 2.5.50.1
Severity: wishlist

Hi Niels et al,

while working on multiarchy stuff again, I needed to figure out which
packages are "empty". Lintian's notion of empty-binary-package was
helpful here, but I figured that it was missing a fair number of
packages that I would characterize as "empty" (mostly searching for
transitional packages). Thus I went ahead and poked at the problem with
the dedup.d.n engine (which is way faster at poking certain binary
package aspects than running lintian across the archive, but also way
more scope limited). I figured that lintian's check could ignore more
files:

 * /usr/share/doc/$package/buildinfo_$architecture.gz is added by
   dh_buildinfo. I understand that this is likely going away with recent
   the uptake of .buildinfo files, but we still have a number of these.
   I believe that presence of such a file doesn't make it non-empty.
 * /usr/share/doc/$package/changelog.Debian.$architecture.gz is added on
   binNMUs to avoid breaking Multi-Arch: same properties. It is never
   present in initial uploads, so unlikely to be encountered by
   developers, but I think it should still be considered.
 * /usr/share/bug/$package/{control,presubj,script} are present in a
   number of otherwise fairly empty packages. It may make sense to
   ignore them in the emptyness check as well.
 * Then I noticed that data/files/standard-files wasn't covering some
   common files. I have a few suggestions here:
    + BUGS and BUGS.gz
    + CHANGES and CHANGES.gz
    + README.Debian and README.Debian.gz <- this one is rather frequent
    + README.md, README.rdoc, and README.source (+ .gz variants)
      (maybe README.*?)
    + NEWS.Debian and NEWS.Debian.gz <- also frequent
    + TODO.Debian and TODO.Debian.gz

In general, the approach discovering these has been:
 1. Import 10% of the archive.
 2. Search for packages with "transitional", "dummy package" or "empty
    package" in their descriptions that are not discovered as empty and
    investigate those.
 3. Back to step 1.

Thus I do not expect too many packages, for which the check becomes a
rejection reason on the next upload (many already contain the
catchphrases).

I hope this is useful. If not, please close as wontfix.

Helmut