apt/test/integration/test-resolver-provider-exchange, branch main Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=main 2025-05-26T10:45:12Z solver3: Assume manual packages 2025-05-26T10:45:12Z Julian Andres Klode jak@debian.org 2025-05-26T09:19:11Z urn:sha1:717ca7922be8a025b8034dc840b2ad9befc3b171 If we have allowed the removal of manual packages, assume them all before starting the solver. This should ensure that as long as there is a solution that does not remove a manually installed package, it is found. This requires a sweeping set of changes in the test suite, but ensures that we get "safe" behavior from the solver. We have in particular seen that without asserting the installed packages, several people ended up with ubuntu-minimal and perl removed in a situation where that was not warranted, that is, they install winehq, and then pull in some new perl packages in a newer version than the installed one, and the solver chose to create a mismatched version set, which then caused the main perl package to not be installable. Oops: 1b55173a-3526-11f0-b7ac-fa163e171f02 Oops: dbd5149e-36b9-11f0-bb74-fa163ec44ecd solver3: Order obsolete choices last 2024-06-13T13:10:06Z Julian Andres Klode julian.klode@canonical.com 2024-06-06T09:19:04Z urn:sha1:6708203296911800caf94bb94ce204d3a39af0bd This has two aspects: 1. For a dependency A | B | C we order the obsolete packages last, that is, if A is obsolete, this gets reordered to B | C | A, such that we try to pick non-obsolete packages first to ease upgrade calculation. 2. When comparing two dependencies, we order dependencies into three groups: First we satisfy dependencies mentioning only non-installed (NEW) packages, then we satisfy "normal" dependencies, and finally we satisfy any dependencies mentioning obsolete packages. This means for example if you have obsolete libfoo1 and a new libfoo1t64, that we will see Depends: libfoo1t64 before any Depends: libfoo1 (which may expand to libfoo1 | libfoo1t64), so we effectively will have selected "replacement" packages this way already before getting to older packages where we would have to choose between the obsolete package and its replacement. solver3: Solve optional dependencies before optional packages 2024-05-24T15:01:55Z Julian Andres Klode julian.klode@canonical.com 2024-05-20T12:59:58Z urn:sha1:cd245a57f273d3c069543c19d6ac31c84879ce7b This somewhat improves reliability of not breaking Recommends, e.g. if the Recommends gets tightened. One test case enabled by this now is the test-resolver-provider-exchange, which with a simple change to allow removal of automatically installed packages works now. test: fixup for hash table size increase (changed output order) 2020-12-15T12:20:16Z Julian Andres Klode julian.klode@canonical.com 2020-12-15T12:20:16Z urn:sha1:b6c8c5ce2b255eb03554435a620934d47a2a14d5 Add dependency points in the resolver also to providers 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T16:49:11Z urn:sha1:1f910d94add8f20ebfa5999a7795e678a4af0826 We were traditionally adding points for some dependency types to the real package, but we should also do it for providers of that package to help the resolver especially if the real package is for some reason not tagged for removal yet/anymore. While at it we ensure that the points are only attributed once for each package as especially with versioned provides a package can nowadays provide another many times and would hence acquire a lot of points.