[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-devel
Subject:    Re: Another take on package relationship substvars
From:       Niels Thykier <niels () thykier ! net>
Date:       2024-02-24 6:57:16
Message-ID: b1efe9b1-8343-43cc-805e-ef31afe4f722 () thykier ! net
[Download RAW message or body]

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.



[prev in list] [next in list] [prev in thread] [next in thread]