On 22.02.24 20:43, Niels Thykier wrote:
Simon McVittie:
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
Package: libgcc-13-dev
Recommends: ${dep:libcdev}
Depends: gcc-13-base (= ${gcc:Version}), ${dep:libgcc}, ${dep:libssp},
${dep:libgomp}, ${dep:libitm},
${dep:libatomic}, ${dep:libbtrace}, ${dep:libasan}, ${dep:liblsan},
${dep:libtsan}, ${dep:libubsan}, ${dep:libhwasan}, ${dep:libvtv},
${dep:libqmath}, ${dep:libunwinddev}, ${shlibs:Depends}, ${misc:Depends}
Some of those are undefined depending on the architecture. And most of
these are unused in other packages, however passing every macro into a
package, independent if it's used or not.
Not seeing any benefit in this feature (hard failure).
Matthias
