Re: Another take on package relationship substvars
Simon McVittie:
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!
Thanks for the feedback.
I was not aware that ${gir:Provides} was new. :) But indeed, I was
hoping the proposal would simplify this kind of roll out in the future!
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.
In my original proposal, I did cover how to make all sorts of exceptions
for this case. But I am not aware of a real case where this matters.
So before I invest in a corner case that might not even exist, is anyone
aware of this being a regular case that might warrant general tool
support? Or we are trying to plug a hole that never was?
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?
Again, before we invest a lot in creating an API for features for this,
do we see cases that need fixing that cannot "just" be solving by
improving the tool providing the substvars itself?
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:
[...]
Reminder: My proposal only covers ${foo:Depends} and similar substvars.
The first example you present uses substvars that do not match that
pattern. Therefore initial reaction is that this effectively ends up
being a straw man argument because it does not correctly account for the
scope of this proposal.
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
Could you please clarify if the rest of this argument is still relevant
given the example seemed to be off? I am happy to entertain it, but I
would prefer working from a state where we both agree that it is
relevant, before I invest effort to understand it.
Best regards,
Niels
Reply to: