Package: libmateweather1 Version: 1.20.0-1 Severity: normal Dear Maintainer,
Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libmateweather1:i386 libmateweather1:amd64 [...] dpkg: dependency problems prevent configuration of libmateweather1:amd64: libmateweather1:i386 (1.20.0-1) breaks libmateweather and is installed. libmateweather1:amd64 (1.20.0-1) provides libmateweather. dpkg: error processing package libmateweather1:amd64 (--configure): dependency problems - leaving unconfigured So the source of the issue seems to be that libquazip5-1: * Provides the libmateweather virtual package * Breaks AND Conflicts with the libmateweather virtual package! * Replaces the libmateweather virtual package Apt seems to consider that this means libmateweather1:amd64 breaks libmateweather1:i386 through the libmateweather virtual package 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 Finally libmateweather may well have been a real package at some point. However currently its only existence is through the Provides of libmateweather1. Still if the goal it to state that libmateweather1 breaks this old package (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. In any case it does not seem like libmateweather1 should combine Breaks and Conflicts. Note that libmate-panel-applet-4-1 has a similar issue with libmatepanelapplet. -- 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 libmateweather1 depends on: ii libatk1.0-0 2.28.1-1 ii libc6 2.27-3 ii libcairo-gobject2 1.15.10-3 ii libcairo2 1.15.10-3 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libglib2.0-0 2.56.1-2 ii libgtk-3-0 3.22.29-3 ii libmateweather-common 1.20.0-1 ii libpango-1.0-0 1.42.0-1 ii libpangocairo-1.0-0 1.42.0-1 ii libsoup2.4-1 2.62.1-1 ii libxml2 2.9.4+dfsg1-6.1 libmateweather1 recommends no packages. libmateweather1 suggests no packages. -- no debconf information
