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
