Bug#901507: lintian: warn if debhelper is in B-D-Arch or B-D-Indep but not Build-Depends
On Sat, 16 Jun 2018 at 18:45:56 +0100, Chris Lamb wrote:
> I'm also seeing a bunch of false-positives in the addon checker -
> using the dh Python addon shouldn't mean that python can't be in
> Build-Depends-Indep. Or dpatch!
Sure - I hadn't intended that you'd add this mechanism for packages that
ship debhelper addons alongside other content, just the ones that have
little or no purpose other than their debhelper addons, like most/all
of the dh-$addon family, and maybe some of the pkg-$team-tools family.
> Hm, Simon, are we not already covered by "clean-should-be-satisfied-by-build-depends"
> here?
I don't think I got that Lintian warning for a simple use of dh in a
package I was looking at recently, but I can't remember which package
now... looking at the Lintian source code, it's grepping for patterns,
but doesn't seem to detect
%:
dh --whatever --options
as needing debhelper for clean?
I think I was mainly approaching this from a different angle than
the clean-should-be-satisfied-by-build-depends implementation.
clean-should-be-satisfied-by-build-depends tries to detect what is
actually needed by 'clean', with a risk of false negatives (not always
warning maintainers if they've made debuild -S fail). My idea was to
assume that all Build-Depends-* are necessary, make use of the fact that
we know certain packages are always or nearly always used via debhelper
sequences, and so recommend that those packages move from B-D-* to B-D,
with a risk of false positives (putting too many packages in B-D and
not enough in B-D-I). I think acting on false positives would be fairly
harmless for most of these packages, since they're small, Architecture:
all, Multi-Arch: foreign and don't have side-effects by being installed,
so having them installed more often isn't going to break cross-compilation
or make builds take significantly longer.
That reasoning doesn't hold for Architecture: any packages (for which
it might complicate cross-compilation) or for documentation toolchains
(which can trigger an "expensive" documentation build if packages have
automagic dependencies, and can take a lot of time/space to install if
they pull in texlive), so those packages should maybe be excluded from
this check as a way to mitigate false positives.
You're right that the clean-should-be-satisfied-by-build-depends tag is
more general than what I proposed in this bug, so the new additions
should maybe emit that tag rather than new tags.
smcv
Reply to: