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

[#16959] Wrong dependency resolution for packages which Conflicts/Replaces/Provides:bar and are M-A:same

Date:
2014-02-02 19:03
Priority:
3
State:
Closed
Submitted by:
Johannes Schauer (josch)
Assigned to:
Roberto Di Cosmo (dicosmo)
Summary:
Wrong dependency resolution for packages which Conflicts/Replaces/Provides:bar and are M-A:same

Detailed description
Consider the following Packages file:

Package: blub
Version: 1.0.1
Architecture: all
Depends: foo:i386, foo:amd64

Package: foo
Version: 1.0-1
Architecture: amd64
Multi-Arch: same
Conflicts: bar
Replaces: bar
Provides: bar

Package: foo
Version: 1.0-1
Architecture: i386
Multi-Arch: same
Conflicts: bar
Replaces: bar
Provides: bar

It should be no problem to install the package blub because the package foo is M-A:same. The fact that it provides a virtual package bar with which it conflicts does not mean that it cannot be installed for multiple architectures at the same time. It's a self-conflict. But I get this:

./distcheck.native --deb-native-arch=amd64 --deb-foreign-archs=i386 --explain --successes --failures --checkonly blub:amd64 deb://test
report:
-
package: amd64:blub
version: 1.0.1
architecture: all
essential: false
source: blub (= 1.0.1)
status: broken
reasons:
-
conflict:
pkg1:
package: amd64:foo
version: 1.0-1
architecture: amd64
essential: false
source: foo (= 1.0-1)
unsat-conflict: i386:--virtual-bar
pkg2:
package: i386:foo
version: 1.0-1
architecture: i386
essential: false
source: foo (= 1.0-1)
depchain1:
-
depchain:
-
package: amd64:blub
version: 1.0.1
architecture: all
essential: false
depends: amd64:foo
depchain2:
-
depchain:
-
package: amd64:blub
version: 1.0.1
architecture: all
essential: false
depends: i386:foo

background-packages: 2
foreground-packages: 1
total-packages: 3
broken-packages: 1

Looking at the created cudf universe reveals:

package: i386%3afoo
version: 2
conflicts: amd64%3abar , amd64%3a--virtual-bar , i386%3abar , i386%3a--virtual-bar , i386%3afoo , amd64%3afoo != 2
provides: foo , i386%3a--virtual-bar
architecture: i386
number: 1.0-1
source: foo
sourcenumber: 1.0-1
sourceversion: 2
replaces: bar , --virtual-bar
essential: false
buildessential: false
type: bin
filename: test
multiarch: same

package: amd64%3afoo
version: 2
conflicts: amd64%3abar , amd64%3a--virtual-bar , i386%3abar , i386%3a--virtual-bar , amd64%3afoo , i386%3afoo != 2
provides: foo , amd64%3a--virtual-bar
architecture: amd64
number: 1.0-1
source: foo
sourcenumber: 1.0-1
sourceversion: 2
replaces: bar , --virtual-bar
essential: false
buildessential: false
type: bin
filename: test
multiarch: same

So the problem seems to be that foo in one architecture conflicts with foo in another architecture. The translation into cudf does not represent that it is the same package foo and that it's just a self-conflict. Instead foo should only conflict with any other provider of bar but not itself in any architecture.

This problem is significant during cross compilation. For example the package linux-libc-dev Conflicts/Replaces/Provides the virtual package linux-kernel-headers. The package linux-libc-dev is also M-A:same. The package linux-libc-dev is also the only provider of linux-kernel-headers. Dpkg and apt have no problem installing linux-libc-dev for multiple architectures but dose3 does not allow this.

Until this problem is fixed, dose3 cannot be used for cross build dependency analysis as one will run into the linux-libc-dev problem.
Message  ↓
Date: 2014-04-09 15:26
Sender: Roberto Di Cosmo

Fixed by commit 74b9811d33ed3706942224722d857f9d24d5c5c0

Date: 2014-04-09 15:24
Sender: Roberto Di Cosmo

Fixed in commit 74b9811d33ed3706942224722d857f9d24d5c5c0

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