Home My Page Projects Dose: library and tools
Summary Activity Tracker Lists SCM Files

[#16979] Doesn't handle versioned Breaks correctly

Date:
2014-02-05 16:05
Priority:
3
State:
Closed
Submitted by:
Johannes Schauer (josch)
Assigned to:
Roberto Di Cosmo (dicosmo)
Summary:
Doesn't handle versioned Breaks correctly

Detailed description
Consider the following dependency situation:

Package: libc6-dev
Version: 2.17-97
Architecture: amd64
Breaks: binutils-gold (<< 2.20.1-11)

Package: binutils
Version: 2.24-3
Architecture: amd64
Provides: binutils-gold

The above are the relevant parts from a current (2014-02-05) Packages file of Debian Sid. libc6-dev and binutils must be installable together because they are both part of build-essential. Dpkg and apt have no problem with installing them together but the versioned Breaks seems to cause trouble for dose3:

$ deb-coinstall -v --failures --explain --bg=sid-amd64-packages.gz test --deb-native-arch=amd64
(I)Packages: Parsing Packages file test...
(I)Format822: total packages 2
(I)Packages: Parsing Packages file sid-amd64-packages.gz...
(I)Format822: total packages 41224
(I)Deb-coinstall: Solving...
report:
-
coinst: amd64:binutils (= 2.24-3) , amd64:libc6-dev (= 2.17-97)
status: broken

reasons:
-
conflict:
pkg1:
package: amd64:libc6-dev
version: 2.17-97
architecture: amd64
essential: false
source: eglibc (= 2.17-97)
unsat-conflict: amd64:--virtual-binutils-gold
pkg2:
package: amd64:binutils
version: 2.24-3
architecture: amd64
essential: false
source: binutils (= 2.24-3)

background-packages: 41224
foreground-packages: 2
total-packages: 41224

The offending Packages file can be found here:

http://snapshot.debian.org/archive/debian/20140205T041353Z/dists/sid/main/binary-amd64/Packages.gz
Message  ↓
Date: 2014-04-09 15:27
Sender: Roberto Di Cosmo

Fixed by commit 74b9811d33ed3706942224722d857f9d24d5c5c0

Date: 2014-02-07 09:43
Sender: Johannes Schauer

correct, in https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual it says:

"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."

It turns out that my initial test input was also just a bit too minimal. The package libc6-dev was missing the Multi-Arch:same stanza. Here is the correct one:

Package: libc6-dev
Version: 2.17-97
Architecture: amd64
Breaks: binutils-gold (<< 2.20.1-11)
Multi-Arch: same

Package: binutils
Version: 2.24-3
Architecture: amd64
Provides: binutils-gold

Now it's enough to run:

./deb-coinstall.native -v --dump=out.cudf --failures --explain --deb-native-arch=amd64 test

without needing the full background universe.

Indeed, when the Multi-Arch:same stanza is removed, they are perfectly co-installable. Here the (relevant parts of the) cudf universe created by above debian binary packages:

package: amd64%3alibc6-dev
version: 2
conflicts: amd64%3abinutils-gold , amd64%3a--virtual-binutils-gold , amd64%3alibc6-dev
provides: libc6-dev
architecture: amd64

package: amd64%3abinutils
version: 4
conflicts: amd64%3abinutils , binutils
provides: binutils , amd64%3a--virtual-binutils-gold
architecture: amd64

The conflict is easily visible. When removing the Multi-Arch:same stanza from libc6-dev, the above becomes:

package: amd64%3alibc6-dev
version: 2
conflicts: amd64%3abinutils-gold < 3 , amd64%3alibc6-dev , libc6-dev
provides: libc6-dev
architecture: amd64

package: amd64%3abinutils
version: 4
conflicts: amd64%3abinutils , binutils
provides: binutils , amd64%3a--virtual-binutils-gold
architecture: amd64

And thus both packages are now co-installable.

So indeed, libc6-dev being Multi-Arch:same introduces the problem here. More precisely, only when libc6-dev is Multi-Arch:same does it conflict with an UNversioned binutils-gold package and only when libc6-dev is Multi-Arch:same does it conflict with the virtual package binutils-gold.

This might also show a potential second bug: the fact that the binutils-gold conflict no longer has the version restriction with Multi-Arch:same enabled?

I hope I didnt press the submit button too early - all this becomes very confusing very fast if one also tries to have all the other multiarch and provides/conflicts permutations in mind :D

Date: 2014-02-06 16:15
Sender: Roberto Di Cosmo

Well, had a better look at this. Versioned conflicts/dependencies/breaks should only be encoded against *real* packages, not against virtual packages. I remember that this was clearly discussed and agreed years ago, and the encoding used now is a reversion.
This is probably yet another side effect of the complications of the multi-arch encoding, and needs investigation.

Date: 2014-02-06 13:27
Sender: Roberto Di Cosmo

Thanks Josh,
this surley comes from the fact that the version goes indirectly through
a provide, and the original encoding of Debian metadata in dose considered
provides as unversioned: in this case binutils is treated as if it
provides *all versions* of binutils-gold, hence the reported conflict.

Could you dig out the precise semantics of Conflicts/Breaks/Provides
relevant to this case in the Debian documentation?

--
Roberto

Field Old Value Date By
status_idOpen2014-04-09 15:22robertodicosmo
close_dateNone2014-04-09 15:22robertodicosmo
assigned_tonone2014-04-09 15:22robertodicosmo