Re: Dependency merging in APT

On Wed, 28 May 2025 at 10:33:26 +0200, Julian Andres Klode wrote:
>gnupg Depends: gpg (>= 2.4.7-19) overlaps Depends: gpg (<< 2.4.7-19.1~)
> -  solutions: ['gpg=2.4.7-19']
> -  eliminated: [] ['gpg-from-sq=0.13.1-3']
>
>Where gpg-from-sq would be considered a valid solution for the
><< depends as it provides 2.2.something, but not the greater
>depends and apt may decide to upgrade gnupg by installing gpg-from-sq.

This seems like a good improvement. But:

>A complete list of mergeable dependencies is attached.

I'm not sure this merging is helpful where the two dependencies are 
virtual packages that happen to be provided by the same real package 
(and others), especially in the presence of "|". For example:

gnome-remote-desktop Depends: systemd | systemd-tmpfiles overlaps Depends: systemd | systemd-sysusers
  -  solutions: ['systemd=257.5-2', 'systemd=257.5-2']
  -  eliminated: ['systemd-standalone-tmpfiles=257.5-2'] ['systemd-standalone-sysusers=257.5-2', 'opensysusers=0.7.3-4.1']

I believe the intention here was that using g-r-d with systemd is 
preferred (by both upstream and Debian's GNOME team), but users of 
non-default init systems can swap it out for another -tmpfiles 
implementation and another -sysusers implementation, for example 
systemd-standalone-tmpfiles and systemd-standalone-sysusers, with a 
command like one of these:

     apt install gnome-remote-desktop systemd-standalone-tmpfiles systemd-standalone-sysusers
     apt install gnome-remote-desktop sysv-rc
     apt install gnome-remote-desktop systemd-

But does the new merging make this impossible, by eliminating the 
alternatives and forcing the preferred version to be taken?

Perhaps disabling this merging when there is a "|" would be helpful? In 
this situation the package's maintainer is specifically accepting the 
possibility that a non-preferred alternative will be chosen.

Or perhaps this merging should be restricted to situations where the 
package name being requested is the same, like the "gpg" in the 
motivating example?

Similar situations:

libsphinxbase3t64 Depends on any implementation of the liblapack.so.3 
ABI, and any implementation of the libblas.so.3 ABI, but the new code 
doesn't allow them to come from separate binary packages:

libsphinxbase3t64 Depends: liblapack3 | liblapack.so.3 overlaps Depends: libblas3 | libblas.so.3
  -  solutions: ['libopenblas0-serial=0.3.29+ds-3', 'libopenblas0-pthread=0.3.29+ds-3', 'libopenblas0-openmp=0.3.29+ds-
3']
  -  eliminated: ['liblapack3=3.12.1-2', 'liblapack3=3.12.1-2'] ['libblas3=3.12.1-2', 'libblas3=3.12.1-2', 'libblis4-se
rial=1.1-2', 'libblis4-pthread=1.1-2', 'libblis4-openmp=1.1-2']

network-manager-applet Depends on any polkit agent implementation, and 
Recommends any fdo Notifications implementation, but the new code 
disregards solutions that aren't an integrated desktop environment that 
happens to provide both sets of functionality from the same binary 
package:

network-manager-applet Recommends: notification-daemon overlaps Depends: policykit-1-gnome | polkit-1-auth-agent
  -  solutions: ['phosh=0.46.0-3', 'gnome-shell=48.1-1', 'gnome-flashback=3.56.0-1', 'cinnamon=6.4.10-1']
  -  eliminated: ['notification-daemon=3.20.0-5', 'xfce4-notifyd=0.9.7-2', 'python3-jarabe=0.121-1', 'plasma-workspace=4:6.3.4-1', 'notify-osd=0.9.35+20.04.20191129-2', 'mate-notification-daemon=1.26.1-1+b3', 'mako-notifier=1.10.0-1', 'lxqt-notificationd=2.1.1-1', 'lomiri=0.5.0-1', 'dunst=1.12.2-1', 'awesome=4.3-7+b2'] ['ukui-polkit=1.2.2.2-1.1+b1', 'polkit-kde-agent-1=4:6.3.4-1', 'mate-polkit=1.26.1-4+b1', 'lxpolkit=0.5.6-2', 'lxqt-policykit=2.1.0-1']

(In particular KDE Plasma users would prefer to have plasma-workspace as 
their Notifications implementation and polkit-kde-agent-1 as their 
polkit agent, both of which are part of a desktop environment that 
integrates this functionality, even though KDE happens to have chosen to 
implement them in different binary packages behind the scenes!)

     smcv