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
signature.asc
Description: signature
