Steve Langasek:
Hi Niels,

On Thu, Feb 22, 2024 at 07:32:21PM +0100, Niels Thykier wrote:
[...]

I am omitting Breaks, Conflicts, and Replaces because I am not aware of any
users of these at the moment. I am open to adding them, if there is a strong
use-case.

One generic case that this doesn't handle is Essential: yes packages.  For
many of these, the ${shlibs:Depends} gets promoted in debian/control to
Pre-Depends, not to Depends.

Maybe it would make sense to auto-aggregate these substvars, *IFF* there is
not already a reference to the substvar in question in the package stanza in
debian/control?  This would provide adequate flexibility for any other
exceptions that might be out there, beyond the Pre-Depends case.

Cheers,

In case of a promotion, it does not matter if ${shlibs:Depends} is applied twice (once in Depends and in Pre-Depends}. You get the dependencies twice and then dpkg will clean up the duplicates in favor of the "strongest" dependency[1]. The hard part is a demotion because this duplication works against you.

Accordingly, the Essential: yes packages that leverage this technique can just keep doing it without any changes or consequences as far as I can tell.

Best regards,
Niels

[1] man:dpkg-gencontrol(1):

       dpkg-gencontrol reads information from an unpacked Debian source tree 
and generates a binary
       package control file (which defaults to debian/tmp/DEBIAN/control); 
during this process it will
       simplify the relation fields.

       Thus Pre-Depends, Depends, Recommends and Suggests are simplified in 
this order by removing
       dependencies which are known to be true according to the stronger 
dependencies already parsed.
       It will also remove any self-dependency (in fact it will remove any 
dependency which evaluates
       to true given the current version of the package as installed).  
Logically it keeps the
       intersection of multiple dependencies on the same package.  The order of 
dependencies is
       preserved as best as possible: if any dependency must be discarded due 
to another dependency
       appearing further in the field, the superseding dependency will take the 
place of the discarded
       one.



Reply via email to