Sam Hartman:
"Simon" == Simon McVittie <s...@debian.org> writes:Simon> On Thu, 16 Jan 2025 at 09:38:38 -0700, Sam Hartman wrote: >> But the meson setup call is in override_dh_auto_configure. I >> don't know at that point how to figure out of I am building arch >> all packages. Simon> I find that it's often better to do this in terms of "am I Simon> building package X?" instead of "am I building arch: all Simon> packages?" because that way, you will also get the correct Simon> answer when dealing with build-profiles. Simon> We do this a lot in GNOME and GNOME-adjacent Simon> packages. Something like this (in this case taken from Simon> gobject-introspection, and enabling/disabling the gtk_doc Simon> option depending on whether we are building the -doc Simon> package): Simon> built_binaries := $(shell dh_listpackages) Okay, so dh_listpackages is smart enough to know what kind of build it is in even when called from override_dh_auto_configure? I didn't know that, and yes it makes this easy. I also had somehow missed the Build-Profiles binary package control field. To confirm, it would be reasonable to mark libpam-doc with Build-Profiles: <!nodoc>
With some limitations, yes. The limitations for `dh_listpackages` are not applicable to this case, but it is a "here by dragons" area that can be confusing when you accidentally run into the dragon's nest. This mail is mostly to serve as a "caveat" for other participants, since the concrete case is fine.
The caveat:When used **inside** an override or hook target as in this case, Yes. When used **outside** of a override or hook target, you might end up with surprising result.
See "Caveats with hook targets and makefile conditionals" from "man dh", which applies equally to variables used outside hook targets.
The implementation details is that `dh` exposes an internal ENV variable that any `Debian::Debhelper::Dh_Lib` based `dh_*` command reacts to that makes it pick up the `-a` or `-i` implied by `build-arch` or `build-indep` that triggered the build for `dh`.
However, `debian/rules` is run once **outside** a hook target (when `dh` scans for hook targets) in dry-run mode. During this parsing, `dh_listpackages` does not know which kind of build it is (`-b`, `-A`, or `-B`) and it therefore assumes a `-b` build listing all binary packages not excluded by Build-Profiles. The conditional must not cause any harm like shadowing a hook target during this dry-run, because then `dh` does not see the hook target and you will end up very confused by why `debhelper` is ignoring your override.
As said in the beginning, the example Simon gave does not have this problem, so that example should be fine. But be careful with `dh_listpackages` based conditionals outside override/hook targets. it is probably not what you want to spend your Debian time debugging. :)
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
