Bug#1001552: Improper detection of tag satisfaction cases in missing-build-dependency-for-dh-addon tag
Package: lintian
Version: 2.111.0~bpo11+1, 2.114.0
I discovered during compilation of a (slightly) older package that still uses a debhelper (>= 12)
compatibility with a debian/compat file stating 12 that the tag missing-build-dependency-for-dh-addon
is unable to detect the fact that dh-autoreconf is needed when debhelper >= 10 is specified in the
control file or in debian/compat. This resulted in the erroneous errors on missing dh-autoreconf
in xca, where it's not needed by debhelper >= 12 with a compat file stating 12.
This does not trigger when using "debhelper-compat (= 12)" in debian/control without the debian/compat
file, however the tag information and description I saw was this when triggered on mentors.debian.org:
autoreconf => dh-autoreconf | debhelper (>= 9.20160403~) | debhelper-compat
This suggests that if in debian/control you have a "debhelper (>= 9.20160403~)" line (which
"debhelper (>= 12)" qualifies), OR you have debhelper-compat, that this should not trigger.
HOWEVER, this triggers unless debhelper-compat is present in the build-depends, suggesting the tag is
NOT being correctly matched during Lintian runs if multi-level compatibility or experimental debhelper
compatibility (hence "debian/compat" and "debhelper >= 12" being present in a given package) based on
what I've read in manpages.
This looks like erroneous tag detection. Note that if you put in dh-autoreconf into build-deps it
triggers the as-expected useless-autoreconf-build-depends tag.
This currently triggers on the XCA package as uploaded to mentors.debian.net yesterday - both versions
of the package (the one with dh-autoreconf in build-deps and the verison with debian/compat and
"debhelper (>= 12)" in debian/control) exist to show this distinction, and both packages in sid sbuild
chroots reproduce this behavior.
Reply to: