Bug#898956: libmateweather1 is marked Multi-Arch: same but is not coinstallable
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
Reply to: