Hi,
when comparing dpkg, apt and dose3 behavior on 7744 synthetic test cases, then
they disagree on 43.5% of them.
I wrote a testsuite which tests the following setup: two packages pkga and pkgb
are to be co-installed on a system with native architecture amd64 and foreign
architecture i386. Both packages can have any Multi-Arch value and be of
Architecture amd64, i386 or all. The package pkga can depend or conflict with
pkgb or the virtual package pkgc in an architecture qualified or unqualified
way and pkgb can provide or not provide pkgc with and without architecture
qualifier. Considering all possible combinations of these properties, one ends
up with 7744 test cases. Dpkg, apt and dose3 are then asked whether pkga and
pkgb can be co-installed or not.
You can find the script here:
https://gitlab.mister-muffin.de/josch/deb-m-a-dep-check
Running it takes about 40 minutes and currently requires that you are on amd64
because the value is hardcoded and dpkg does not allow changing the native
architecture.
You can find the test results that differed between the three here:
https://mister-muffin.de/p/ze5f.txt
The file has 11 columns, where the first eight column completely describe each
test case and the last three display whether dpkg, apt and dose find the
situation to be satisfiable ("sat") or not ("unsat"). The file only shows the
3367 lines where dpkg, apt and dose3 did not agree about the correct solution.
The columns contain in order:
1. pkga is a binary or source package (this is limited to "binary" for now)
2. Provides of pkgb (can be one of "none" (which means: no provides), "pkgc",
"pkgc:amd64" and "pkgc:i386")
3. Architecture of pkga (either "all", "i386" or "amd64")
4. Architecture of pkgb (either "all", "i386" or "amd64")
5. Multi-Arch value of pkga (either "no", "same", "foreign" or "allowed")
6. Multi-Arch value of pkgb (either "no", "same", "foreign" or "allowed")
7. Relationship of pkga toward pkgb (can be one of "depends" or "conflicts")
8. dependency/conflict of pkga (can be one of "pkgb", "pkgb:amd64",
"pkgb:i386", "pkgb:any", "pkgc", "pkgc:amd64", "pkgc:i386", "pkgc:any")
9. Result of dpkg ("sat" or "unsat")
10. Result of apt ("sat" or "unsat")
11. Result of dose3 ("sat" or "unsat")
Here are some more statistics of the results:
Dpkg and apt agree but dose3 does not: 18.1%
Dpkg and dose3 agree but apt does not: 4.7%
Apt and dose3 agree but dpkg does not: 20.7%
From the test data I think I can at least identify the following cases:
1. dose does not handle architecture qualified provides
-------------------------------------------------------
This is this bug
https://gforge.inria.fr/tracker/index.php?func=detail&aid=18535&group_id=4395&atid=13808
2. dependencies of the form foo:any on a package foo that is not M-A:allowed
----------------------------------------------------------------------------
This can happen when either ":any" is wrongly added or if the package "foo"
switches from being M-A:allowed to something else (without adjusting all of its
reverse dependencies) or if an external package repository contains a package
named "foo" but without it being M-A:allowed there. The question is: should the
resolver count this dependency as satisfied or not? Dpkg seems to think "no
never" while apt seems to allow it "sometimes" (didn't figure out the rule).
3. architecture qualified dependencies on M-A:foreign packages
--------------------------------------------------------------
This is the topic of the thread starting with <[🔎] 20150417092706.GC9295@crossbow>
4. apt does not treat provides or conflicts to be implicitly :any
-----------------------------------------------------------------
This is bug #770345 and somebody has to convince me again that provides should
by implicitly treated as being :any. Is there an easy way to create a binary
package with architecture specific provides depending on the architecture the
package is built for? This seems to be a question of what is the sanest
default.
There are certainly more things to be found in there.
I still hope that some of the disagreements are just a result of me operating
dpkg/apt/dose3 in a wrong way and thus getting wrong answers from them (I
already discovered bug #377860).
I talked to Holger Levsen and he agreed that this script can be run regularly
on jenkins to track the progress on making dpkg, apt and dose3 agree on how
they resolve dependencies involving multiarch.
cheers, josch
Attachment:
signature.asc
Description: signature