Package: libquazip5-1 Version: 0.7.3-7 Severity: normal Dear Maintainer,
Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libquazip5-1:i386 libquazip5-1:amd64 [...] Unpacking libquazip5-1:amd64 (0.7.3-7) ... dpkg: dependency problems prevent configuration of libquazip5-1:amd64: libquazip5-1:i386 (0.7.3-7) breaks libquazip-qt5-1 and is installed. libquazip5-1:amd64 (0.7.3-7) provides libquazip-qt5-1. libquazip5-1:i386 (0.7.3-7) breaks libquazip1-qt5 and is installed. libquazip5-1:amd64 (0.7.3-7) provides libquazip1-qt5. dpkg: error processing package libquazip5-1:amd64 (--configure): dependency problems - leaving unconfigured So the source of the issue seems to be that libquazip5-1: * Provides the libquazip-qt5-1 and libquazip1-qt5 virtual packages * Breaks + Replaces the libquazip-qt5-1 and libquazip1-qt5 virtual packages Apt seems to consider that this means libquazip5-1:amd64 breaks libquazip5-1:i386 through the libquazip-qt5-1 and libquazip1-qt5 virtual packages which prevents them from being coinstalled. One strange thing is that, if I understand 7.6.1 of the Debian Policy Manual correctly, Breaks + Replaces is not supposed to be used on virtual packages: http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s7.6.1 | For this usage of Replaces, virtual packages (see Virtual packages - Provides, | Section 7.5) are not considered when looking at a Replaces field. The packages | declared as being replaced must be mentioned by their real names. Maybe that's why Apt is confused in this multi-arch configuration. Note that, based on 7.6.2, the usual pattern for virtual packages would be Provides + Conflicts + Replaces: | In this situation, the package declared as being replaced can be a virtual | package, so for example, all mail transport agents (MTAs) would have the | following fields in their control files: | | Provides: mail-transport-agent | Conflicts: mail-transport-agent | Replaces: mail-transport-agent | | ensuring that only one MTA can be unpacked at any one time Seems like something to try to see if it fixes the issue. But libquazip-qt5-1 and libquazip1-qt5 may well have been real packages at some point. However currently their only existence is through the Provides of libquazip5-1. Still if the goal it to state that libquazip5-1 breaks these old packages (to ensure clean upgrades), then a Breaks + version number would probably be the right thing to do (see 7.5 of the policy): http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s-virtual | If a relationship field has a version number attached, only real packages will | be considered to see whether the relationship is satisfied (or the prohibition | violated, for a conflict or breakage). In other words, if a version number is | specified, this is a request to ignore all Provides for that package name and | consider only real packages. The package manager will assume that a package | providing that virtual package is not of the "right" version. A Provides field | may not contain version numbers, and the version number of the concrete package | which provides a particular virtual package will not be considered when | considering a dependency on or conflict with the virtual package name. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 4.16.0-1-686-pae (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libquazip5-1 depends on: ii libc6 2.27-3 ii libgcc1 1:8.1.0-1 ii libqt5core5a 5.10.1+dfsg-6 ii libstdc++6 8.1.0-1 ii zlib1g 1:1.2.11.dfsg-1 libquazip5-1 recommends no packages. Versions of packages libquazip5-1 suggests: pn libquazip-doc <none> -- no debconf information
