[Qa-jenkins-dev] dpkg, apt and dose3 do not agree in many synthetic dependency situations involving multiarch

Wed Aug 17 04:25:57 UTC 2016

Hi Jenkins people,

I want to submit a new jenkins job (patch attached) which implements a check
whether dpkg, apt and dose3 agree on how to resolve dependencies involving
multiarch. Below mail describes my original implementation from last year.
Essentially, the test creates all possible combinations of how two packages can
relate to each other and then throws the situation at dpkg, apt and dose3
respectively and checks whether the packages can be installed together or not.
Since our dependency system is complex, it is possible to come up with 8624
ways how two packages can relate to each other. Since my message last year, I
did a complete rewrite of the script and it now also supports source package
dependencies.

Please adjust the trigger time for this job as appropriate. I think running
this once per week would be sufficient.

Maprepi already pointed out that the name is bad. I don't mind any renaming. I
just lack creativity to come up with a good name.

Thanks!

cheers, josch

Quoting Johannes Schauer (2015-04-18 23:24:13)
> 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 at 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-job-cfg-deb-m-a-dep-check.yaml.patch
Type: text/x-diff
Size: 1941 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/qa-jenkins-dev/attachments/20160817/95f2e426/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/qa-jenkins-dev/attachments/20160817/95f2e426/attachment.sig>