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