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

[Simon McVittie]

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

[Chris Lamb]

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,

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

Good idea. Cloning bug to match so we can implement & release
these independently.


Regards,

--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-

[Chris Lamb]

tags 901507 + pending
thanks

Fixed in Git, pending upload:

https://salsa.debian.org/lintian/lintian/commit/9bed2a0905296fae83c23561a70c838198c05fc3

checks/fields.desc | 23 ++++++++++++++++++++++
checks/fields.pm | 6 ++++++
debian/changelog | 3 +++
.../debian/debian/control.in | 16 +++++++++++++++
.../fields-debhelper-in-build-depends-arch/desc | 6 ++++++
.../fields-debhelper-in-build-depends-arch/tags | 2 ++
.../debian/debian/control.in | 16 +++++++++++++++
.../fields-debhelper-in-build-depends-indep/desc | 5 +++++
.../fields-debhelper-in-build-depends-indep/tags | 1 +
9 files changed, 78 insertions(+)

[Chris Lamb]

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(-)

[Chris Lamb]

tags 901507 - patch pending
tags 901631 - patch pending
thanks

Chris Lamb wrote:

> Fixed in Git, pending upload:
>
> https://salsa.debian.org/lintian/lintian/commit/9bed2a0905296fae83c23561a70c838198c05fc3

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?

[Simon McVittie]

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

[Chris Lamb]

Hi Simon,

> [..] like most/all of the dh-$addon family, and maybe some of the
> pkg-$team-tools family.

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

> [lintian] doesn't seem to detect

>
> %:
> dh --whatever --options
>
> as needing debhelper for clean?

Is that because it doesn't see a dh_* command?

> 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.

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?

[Simon McVittie]

On Wed, 21 Feb 2024 at 21:55:08 +0100, Niels Thykier wrote:

> On Mon, 18 Jun 2018 12:16:55 +0100 Simon McVittie <sm...@debian.org> wrote:
> > 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.
>

> 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.

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