On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote:
> I think our package helper tooling should just automatically aggregate all
> provided substvars of the format ${*:Depends} and append it the Depends
> field. Rinse and repeat for other relationship fields.
I recently added ${gir:Provides} to dh_girepository, and the proposed
feature would have meant instant wide adoption without source changes.
So I like this plan!
The only thing I'm wary of is that if the helper tools might sometimes
generate a substvar that is well-meaning but inappropriate (even in corner
cases), we might need an off-switch for this behaviour. At the moment you
can just not add the substvar (and silence or ignore the lint warnings),
but the proposed change would make that impossible.
On the dependency side, dpkg-shlibdeps already has -dRecommends, -dSuggests
and so on, but not all other helpers have this (e.g. #934893), and
maybe it would be useful to have a conventional option to turn off the
dependency-generation altogether in the hopefully rare cases where it
does more harm than good?
On the Provides side, I don't think there's any similar convention.
> We could also make unused substvars a hard failure (FTBFS).
I'd prefer not this, because this would be really painful if you're
using substvars for something other than a simple list of dependencies,
like gobject-introspection does:
Package: gobject-introspection
Depends: binutils-${local:DEB-HOST-GNU-TYPE-DASHES}:any,
gcc-${local:DEB-HOST-GNU-TYPE-DASHES},
gobject-introspection-${local:DEB-HOST-ARCH-OS}-${local:DEB-HOST-ARCH-ENDIAN}-endian
(= ${binary:Version}),
...
Description: ...
... The versions of these tools with
architecture name prefixes, such as ${local:DEB-HOST-GNU-TYPE}-g-ir-scanner,
...
I'd prefer not to put lots of glue into debian/rules to generate these
substvars for precisely the packages that use them, because that's
another thing to keep in sync between d/control and d/rules (so at the
moment I'm ignoring dpkg-gencontrol's complaints about these substvars
being mentioned in some but not all binary packages).
Conversely, I could have implemented most of this by generating per-package
${local:Provides} and ${local:Depends}, but if I did that, then I'd have to
encode half of each binary package's dependencies in d/rules.
I'd prefer to be able to look at d/control and see the overall "shape" of
the interdependencies - "this Depends on binutils-something:any,
gcc-something, ..." - rather than having that information in d/rules.
smcv
