On Wed, 21 Feb 2024 at 21:55:08 +0100, Niels Thykier wrote:
> On Mon, 18 Jun 2018 12:16:55 +0100 Simon McVittie <s...@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
