Re: Another take on package relationship substvars

[Matthias Klose <doko@debian.org>]

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