Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=3.1.8 2025-02-14T18:08:45Z 2025-02-14T18:08:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-11T21:03:03Z urn:sha1:3ae41a76c19e5ad05600188de43b46c3e2800676 This was a rather silly way to communicate state, and it was in the wrong place. Notably also, multiple calls to the solver had the options sticky, that is, if you run upgrade and then it calls ResolveByKeep(), for example. 2024-05-14T09:56:18Z Julian Andres Klode julian.klode@canonical.com 2024-05-06T13:34:33Z urn:sha1:89dcc342e17dd2439d97a5d27200cf5c26ba35bc This is a simple backtracking brute-force solver with heurisitcs, this initial version has the following known gaps: - Errors are not kept from branches, the error reporting after backtracking isn't particularly useful. - We cannot show automatically removed packages - We cannot replace packages with others - We do not have conflict-driven clause learning yet Untested: - Multi-arch This solver is fundamentally different in key aspects: - It solves smaller dependency groups before larger ones, leading us to avoid installing A in A|B if B is installed more often and more consistently. - It only keeps the automatic packages reachable via the strongest path. Currently it only implements autoremoval, but not display of autoremoval as we simply enqueue all automatically installed packages at the end when not doing automatic removal. This will need some translation where we Solve() first, and then Solve() again with the automatically installed packages added such that we can mark them as Garbage for display purposes. - It does not remove manually installed packages. Hook the solver in via the EDSP framework, this allows us to achieve easy initial integration without lots of issues. A lot of this work was planned and executed in my free time and then some leaked into work time I suppose. Implementation notes: - Restore the full backlog of items The annoying thing is that we record only when an item was enqueued and not the level at which it was installed, so when going back a decision level we might have to reinstall packages that were queued at an earlier decision level because they were only installed at a later decision level. - When picking one version, reject the others - Propagate conflicts up to reverse dependencies This will recursively mark every reverse dependency that can no longer be satisfied as MUSTNOT. Also make sure to recursively call Reject(Ver) from Reject(Pkg) to make sure we trigger the Rejections there. This means we now end up having Recursion in the algorithm. An alternative approach would be to push *reject* items to the heap and then do them, but this is not entirely straight forward and it may simply not be necessary. - Sort upgrades before other optional installs containing subsets If I want to upgrade a package A, I schedule A3|A2|A1; if another thing depends specifically on A1; we'd not be installed. Hence we need to sort upgrades first. This only is needed for optional packages; manual packages will figure this out naturally. - Rescoring is lazily implemented. Instead of calling make_heap() after rescoring items, we just mark the items as dirty and reinsert them. We also only rescore from the main solve loop, Reject() marks the heap as needing a rescore due to a Conflict (as some versions will no longer be installable), and RescoreWorkIfNeeded() then will do the rescoring. - Recursive unit propagation: Install() and Reject() recursively call each other to promote decisions across single-version dependencies (or across not-anymore satisfiable reverse-depends). - Make Reason constructors explicit, this enhances readability This makes calls like the one in here be Reject(object, Reason(otherObject)) Ensuring that it's clear that the 2nd argument is a reason at the caller side. - Split Decision into Decision and Hint vs. first draft When branching/deciding, we do not want to override SHOULD and MAY. We do not actually use them yet, and we do actually clean them when backtracking, but let's at least keep the data structure correct. Convert the enum to a 16-bit integer so we can still fit in the same space as before. 2024-02-13T13:27:27Z Julian Andres Klode julian.klode@canonical.com 2024-02-12T13:48:48Z urn:sha1:a8352c2859a6f84b36fa5cd0af89231cb656b1ce This moves the functions of the PhasedUpgrader class into various other classes so they can be publicly exposed. This introduces three new functions: pkgDepCache::PhasingApplied() tells you whether phasing should be applied to the package. pkgProblemResolver::KeepPhasedUpdates() keeps back updates that have phasing applied. pkgCache::VerIterator::IsSecurityUpdate() determines whether this version contains security fixes. 2024-02-13T13:13:56Z Julian Andres Klode julian.klode@canonical.com 2024-02-13T12:58:40Z urn:sha1:26e0e9b76fb06afe5250eeb8e5b3d069d4793432 We only considered an update a security update if a previous update is a security update but not the update in question itself. LP: #2051181 2023-07-07T12:28:59Z Julian Andres Klode julian.klode@canonical.com 2023-07-07T12:24:52Z urn:sha1:68ef41ea912f4879b0ee43419c13a3a8c9bfcd22 This fixes an issue where phased updates gain new dependencies and cause them to be installed despite themselves not being installed. In the cause of investigation, it turned out that we also need to evaluate the candidate version at those early stage rather than the install version (which is only valid *after* MarkInstall). This does not fully resolve the problem: If an update pulls in a phased update, depends are still being installed. Resolving this while ensuring that phased updates cannot uninstall packages requires us to do a minimization of changes by trying to keep back each new install removal and then seeing if any dependency is being broken by it. This is more complex and will happen later. 2023-07-05T08:57:26Z Julian Andres Klode julian.klode@canonical.com 2023-07-03T09:13:00Z urn:sha1:89dd48bdea93849246fc33b447d6d7ad52bb1c4b In the bug, mutter was kept back due to phasing and the new gnome-shell depended on that, and was therefore kept back as well, however, gnome-shell-common was not broken, and apt decided to continue upgrading it by removing gnome-shell and the ubuntu desktop meta packages. This is potentially a regression of LP#1990586 where we added keep back calls to the start of the dist-upgrade to ensure that we do not mark stuff for upgrade in the first place that depends on phasing updates, however it was generally allowed by the resolver to also do those removals. To fix this, we need to resolve the update normally and then use ResolveByKeepInternal to keep back any changes broken by held back packages. However, doing so breaks test-bug-591882-conkeror because ResolveByKeep keeps back packages for broken Recommends as well, which is not something we generally want to do in a dist-upgrade after we already decided to upgrade it. To circumvent that issue, extend the pkgProblemResolver to allow a package to be policy broken, and mark all packages that already were already going to be policy broken to be allowed to be that, such that we don't try to undo their installs. LP: #2025462 2022-09-28T14:32:44Z Julian Andres Klode julian.klode@canonical.com 2022-09-28T14:28:36Z urn:sha1:5f5a8deedffac3cdeeb2f178d910d3759d366e8e By marking them at the end, we might make other decisions that depend on the new phased updates, confusing the solver. Run the marking at the start too. The EDSP test file from Jeremy was modified to include Machine-ID and Phased-Update-Percentage fields and then filtered to mostly exclude packages irrelevant to the test case by running grep-dctrl \( -FRequest "EDSP 0.5" -o -FInstalled yes \ -oFPhased-Update-Percentage 10 \) \ -a --not -FArchitecture i386 LP: #1990586 2022-06-28T12:25:18Z Julian Andres Klode julian.klode@canonical.com 2022-06-24T14:09:24Z urn:sha1:db131677bee45c86031d37d7b451e6ece692efb2 This is a lot closer to the original implementation in update-manager, but still has a couple of differences that might cause bugs: - When checking whether a version is a security update, we only check versions in between and not any later version. This happens mostly because we do not know the suite, so we just check if there is any version between the installed version and our target that is a security update - We only keep already installed packages, as we run before the resolver. update-manager first runs the resolver, and then marks for keep all packages that were upgraded or newly installed that are phasing (afaict). This approach has a significant caveat that if you have version 1 installed from a release pocket, version 2 is in security, and version 3 is phasing in updates, that it installs version 3 rather than 2 from security as the policy based implementation does. It also means that apt install does not respect phasing and would always install version 3 in such a scenario. LP: #1979244 2019-02-26T15:31:20Z Julian Andres Klode julian.klode@canonical.com 2019-02-26T10:33:11Z urn:sha1:eeecbe521fdad69a924992f505d0a32b53800cfc 2017-07-12T11:57:51Z Julian Andres Klode jak@debian.org 2017-07-12T11:40:41Z urn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3 This makes it easier to see which headers includes what. The changes were done by running git grep -l '#\s*include' \ | grep -E '.(cc|h)$' \ | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/' To modify all include lines by adding a space, and then running ./git-clang-format.sh.