Bug#901507: lintian: warn if debhelper, dh-* are in B-D-Arch or B-D-Indep but not Build-Depends

[Simon McVittie <smcv@debian.org>]

Package: lintian
Version: 2.5.90
Severity: wishlist

Packages that use debhelper normally invoke it in their clean target,
which according to Policy §7.7 can only rely on having the Build-Depends
available. If a source package only provides Architecture: all binaries,
maintainers are often tempted to put debhelper in Build-Depends-Indep,
but that would make `sbuild --dist=unstable --source --no-arch-any .`
(normally a way to build a clean, canonical source package) fail.
Similarly, if a source package has no Architecture: all binaries,
maintainers might be tempted to put debhelper in Build-Depends-Arch,
but that will cause the same command to fail.

I think it would be useful for lintian to issue a
warning in this case, similar to the experimental
libmodule-build-perl-needs-to-be-in-build-depends and
libmodule-build-tiny-perl-needs-to-be-in-build-depends tags.

The same is true for packages that provide debhelper sequences.
`apt-file search /usr/share/perl5/Debian/Debhelper/Sequence` tells me
there are more packages providing debhelper sequences than I had expected,
so it might be best if this warning is issued for packages that are
normally only useful as a source of debhelper addons, such as dh-*,
pkg-kde-tools and pkg-php-tools, but maybe not (for example)
bash-completion, cme or gem2deb.

Maybe debhelper-needs-to-be-in-build-depends for debhelper itself and
debhelper-addon-needs-to-be-in-build-depends for build systems and
sequences?

debhelper-like frameworks like cdbs have the same issue. cdbs is
probably the only one common enough to justify its own tag.

Regards,
    smcv