Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=main 2025-05-26T10:45:12Z 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 2024-05-24T15:01:35Z Julian Andres Klode julian.klode@canonical.com 2024-05-19T18:04:47Z urn:sha1:b5997949909ee9d5e9981c8311aea97c7b2620fd Highlights: - test-bug-618848-always-respect-user-requests: (Do not) Support 3.0 solver A manually installed package is never removed just because we request the removal of its dependency in solver3. - test-bug-657695-resolver-breaks-on-virtuals: Support 3.0 solver For manually installed packages, solver 3.0 would require some new xserver-xorg-video-driver to Conflict+Replace+Provides the old one (once the logic is implemented), but that does seem reasonable. - test-bug-720597-build-dep-purge: Support 3.0 solver This needs a simple aptmark auto because pkga is removed by the build-dep. But further adjustments are necessary because it weirdly tested for no autoremovable packages before installing pkgc. - test-bug-960705-*: Support 3.0 solver Bit awkward to deal with; notably the protect to conflict doesn't actually work anymore and that is a feature these days. 2023-11-22T15:33:45Z Julian Andres Klode julian.klode@canonical.com 2023-11-22T15:22:07Z urn:sha1:b0e336787be8a73280cf4cf037295c6347bcbd83 In "Restore ?garbage by calling MarkAndSweep before parsing" I made install code run MarkAndSweep before parsing arguments such that the "?garbage" pattern works correctly. This caused test suite breakage because packages now ended up with marked flags in the debug output. Hence add "m" to the output we assert where necessary. In a nicer world we might want to just do MarkAndSweep if we actually have a ?garbage pattern to evaluate but that is a bit unpredictable in terms of performance expectations and because a "read-only" construct modifies the depcache, so let's go with the more expected option for now Regression-of: b6f362e8013b03efce54e7381e0e22fac1fa1539 2021-04-26T11:00:24Z David Kalnischkies david@kalnischkies.de 2021-03-18T16:37:49Z urn:sha1:d6f3458badf2cfea3ca7de7632ae31daff5742be An interactive tool like aptitude needs these flags current far more often than we do as a user can see them in apt only in one very well defined place – the autoremove display block – so we don't need to run it up to four times while a normal "apt install" is processed as that is just busywork. The effect on runtime is minimal, as a single run doesn't take too long anyhow, but it cuts down tremendously on debug output at the expense of requiring some manual handholding. This is opt-in so that aptitude doesn't need to change nor do we need to change our own tools like "apt list" where it is working correctly as intended. A special flag and co is needed as we want to prevent the ActionGroup inside pkgDepCache::Init to be inhibited already so we need to insert ourselves while the DepCache is still in the process of being built. This is also the reason why the debug output in some tests changed to all unmarked, but that is fine as the marking could have been already obsoleted by the actions taken, just inhibited by a proper action group. 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T11:58:35Z urn:sha1:cfd0172fb0eeb15b2e2427c0e11b2ec65f501839 If the package providing the given solution is tagged already for removal (or at least for "not installing") we can ignore this solution as a possibility as it is not one, which means we can avoid exploring the option and potentially forward the protected flag further if that helps in reducing the possibilities to a single one. 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T11:14:33Z urn:sha1:3e39efa31da463ca05016513835d9a5388f80f90 Marking a package for removal is fine if we know that we have to remove that package, but if we are in an alternative branch we might not go this route in the end and hence have a package pointlessly marked for removal which isn't questioned later on. We check if we are allowed to remove that package to avoid working on the positive dependencies if not, but we mark them for removal only after all the other dependencies are successfully resolved. In an ideal world we would let the problemResolver do its job on them, but the resolver might decide against doing the removal exploring another option like the next alternative, which might be a good idea, but is not the behaviour we had before, so that is the best we can do for now without changing the resolver drastically.