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
clone 901507 -1 retitle -1 lintian: warn if dh-* sequence is in B-D-Arch or B-D-Indep but not Build-Depends retitle 901507 lintian: warn if debhelper is in B-D-Arch or B-D-Indep but not Build-Depends thanks Hi Simon, Good idea. Cloning bug to match so we can implement & release these independently. Regards,
tags 901631 + pending thanks Also fixed in Git, pending upload: https://salsa.debian.org/lintian/lintian/commit/4a60c6620c8e20d9db0990dd18a582fd345e702e checks/fields.desc | 22 ++++++++++++++++++++++ checks/fields.pm | 15 ++++++++++----- debian/changelog | 2 ++ .../debian/debian/control.in | 2 +- .../fields-debhelper-in-build-depends-arch/desc | 1 + .../fields-debhelper-in-build-depends-arch/tags | 3 ++- .../debian/debian/control.in | 2 +- .../fields-debhelper-in-build-depends-indep/desc | 1 + .../fields-debhelper-in-build-depends-indep/tags | 3 ++- 9 files changed, 42 insertions(+), 9 deletions(-) Regards,
tags 901507 - patch pending tags 901631 - patch pending thanks Chris Lamb wrote: Hm, Simon, are we not already covered by "clean-should-be-satisfied-by-build-depends" here? 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! For example: @@ -42,6 +42,8 @@ W: scripts source: binary-arch-rules-but-pkg-is-arch-indep W: scripts source: build-depends-on-obsolete-package build-depends-indep: dpatch W: scripts source: changelog-should-mention-nmu +W: scripts source: debhelper-addon-needs-to-be-in-build-depends Build-Depends-Indep: dpatch +W: scripts source: debhelper-addon-needs-to-be-in-build-depends Build-Depends-Indep: python W: scripts source: debhelper-but-no-misc-depends scripts W: scripts source: debhelper-compat-file-is-missing W: scripts source: debian-watch-file-declares-multiple-versions line 7 fail tests::legacy-scripts: output differs! Thoughts? Regards,
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.
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
Hi Simon, We would need to curate such a list — the code that was flagging up "dpatch" and friends was iterating over: https://salsa.debian.org/lintian/lintian/blob/master/data/common/dh_addons Is that because it doesn't see a dh_* command? I'm not really that fussed about which tag emits it. :) More that it looks like we half do this already and when running the testsuite against my checks for these new tags, it flagged an existing testcase aforementioned tag :) Perhaps getting some concrete positives and false-positives from yourself would be the best, clearest and most efficient way forward here? Regards,
Hi, Drive by remark from the debhelper maintainer. Some dh add-ons can be in ``Build-Depends-Indep`` now and is used to support cross-building in some cases. I do not remember when the feature was added though, so it might not have been possible at the time this was filed. It is hard to tell which add-ons can be in B-D-I, and which cannot. If lintian is going to warn about it, I would recommend a static data list for this. Best regards, Niels
If I remember correctly, the reason I opened the bug is that while
doing unrelated bug-fixing I was seeing a significant number of source
packages that failed to `debian/rules clean` if you install only the
Build-Depends. The typical scenario was that a source package that only
builds Architecture: all binaries would have debhelper or a sequence addon
that runs during clean (like gnome-pkg-tools) in its Build-Depends-Indep.
At the time I opened this bug, I think the only way to activate a sequence
addon was like `dh $@ --with gnome`, which is difficult to set up to
happen conditionally for some but not all builds.
I think the whole dh-sequence-foo mechanism was added since then, and
is a big improvement. Yes, if an addon is activated via dh-sequence-foo
(for example "Build-Depends(|-Arch|-Indep): dh-sequence-gnome"), then it
can be in Build-Depends-Indep, and it will just not be activated during
-B builds. For some addons this is normal, and for some addons this will
mean it doesn't work as intended - it depends what the addon does. But,
either way, that isn't going to break the ability to `debian/rules clean`
without the addon. So I think it would make sense for the the
dh-sequence-foo names to be excluded from any check that is intended to be
a solution for this bug.
smcv