Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=main 2025-10-25T20:16:54Z 2025-10-25T20:16:54Z Julian Andres Klode jak@debian.org 2025-10-25T19:31:34Z urn:sha1:a3fca052ca21ad222ac7f2fdd7f3fe84b44beb60 2025-01-30T13:50:15Z Julian Andres Klode julian.klode@canonical.com 2024-11-02T12:55:39Z urn:sha1:3523efb15d48ce3c6f9212f50dfc892497ba9dcb Instead of directly propagating in a recursive fashion, queue propagations in a queue and work on them in a loop per the miniSAT paper. We call Propagate() only at the end of the FromDepCache() function and then in the Solve loop. Delaying the initial propagation means that we get a stronger reasoning: Assume you have x->a->b->c, y->c and you install x,y: - Previously we traversed: x, y, x->a, a->b, b->c, (y->c) - but now we traverse: x, y, x->a, y->c, a->b, (b->c) Notably c now has the implication y->c instead of x->a->b->c. Inside the solver we need to call Propagate in a loop: Propagating facts can fail and we then backtrack. If backtracking is succesful, we have gained a new fact to propagate. 2024-11-02T09:23:15Z Julian Andres Klode julian.klode@canonical.com 2024-08-01T06:51:37Z urn:sha1:c1f69a64fd5070723ef425cc1255cde2a28966ad These are taken roughly from the MiniSAT paper. We still have a bit to go in actually encoding all clauses so the reasons are still variables, and Assume() isn't fully working yet. Adjust the existing Install()/Reject() code to use these functions, we already see additional lines in the log that we failed to log before, and this ensures more consistency. This is sort of still the wrong direction: Install()/Reject() do the propagation too; but that is tbd. 2024-07-01T19:49:26Z Julian Andres Klode julian.klode@canonical.com 2024-06-13T15:55:10Z urn:sha1:b69f11fac9f4df52726ea7ac4f2c5920b7f71ccb Refactor the various Install requests into a single one and move some stuff around, this should be a bit easier to maintain and we don't repeat ourselves all the time. This accidentally uncovered some bugs in the code, that get fixed by this: - The UpgradeManual and InstallManual groups did not work correctly, Essential packages were Install and others were Upgrade. - Automatically installed packages falsely got promoted to the manual groups as they got promoted into the manual code path, whenever we ran without allowing their removal. - The combination of --mark-auto --auto-remove now works correctly We previously skipped the installation of automatically installed packages when we did autoremoval, but we did not consider if the action was protected, that is specified on the command-line. Now we do not autoremove protected actions, and have added a test case for it. - The AllowRemoveManual option no longer is applied if removals are generally denied. Closes: #1071519 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. 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-05-19T09:22:19Z David Kalnischkies david@kalnischkies.de 2020-05-19T09:20:28Z urn:sha1:dcd920e99df964d320e18ac133d575d4151deb85 References: dcdfb4723a9969b443d1c823d735e192c731df69