Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=main 2026-02-17T09:28:17Z 2026-02-17T09:28:17Z Julian Andres Klode jak@debian.org 2026-02-17T09:28:17Z urn:sha1:9f3ecca2b32e4fe56a05811392e01416092f85fa Implement the "APT::Get::Upgrade-By-Source-Package" option as the classic solver does. Here this is equally straight forward now: We enqueue optional, but eager, clauses of the form foo=2 -> foo-data=2 for each sibling in the source version, assuming they are currently installed, and the selection is not the current version. This softly enforces upgrades of already installed siblings, but in non-strict-pinning mode it will not affect the selection of new packages to be installed. A more complete solution to version selection by source package also seems feasible, where we change the "priority" of versions in the solver dynamically - currently they are statically evaluated. Such that, when you select foo=2, and something installs foo-data, foo-data would be installed in version 2 even if version 3 were its candidate. 2025-03-12T17:54:25Z Julian Andres Klode julian.klode@canonical.com 2025-03-12T17:47:55Z urn:sha1:460753f991ca42c3c4a5ed494038db76c55e2a08 Reorder the if branches a bit to simplify the understanding of the promotions, and allow us to keep track of which dependency existed in the installed version. Change the rule for promoting new recommends to only promote new recommends to depends in *upgrade* and not *dist-upgrade* per the test-resolve-by-keep-new-recommends test case. This makes some sense: In a dist-upgrade, the solver could otherwise decide to remove an installed package if both the following hold: (1) something needs the upgraded version | something else (2) the upgraded version is not installable due to unsat recommends 2025-02-18T09:56:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-17T20:42:29Z urn:sha1:4175a005f98dba139208035d820bcc14de711a5a Implement the moving of the auto bit. The whole auto-bit management is not entirely optimal yet, but this works. 2025-02-14T18:08:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-11T23:07:30Z urn:sha1:cfb8a9e8610d9595a6c1f8368835e7cfbcf67cc5 2025-02-14T18:08:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-11T21:13:27Z urn:sha1:9028df1955a914230ba772776bac7fa0fb530ecf This allows it to work with solver3 before that feature is implemented. This essentially reverts the change to that test made in 119a8d0ed19a4e946591b9aef7d662e14ca7ece5 2025-02-14T18:08:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-11T21:04:17Z urn:sha1:47b227a6dd609528a9f9f5c46d74f95919e21826 When we call an EDSP solver from ResolveByKeep(), we are not in an upgrade context: In an upgrade context, we call the solver directly from upgrade.cc instead of doing any Resolve() or ResolveByKeep() calls. This fixes the test-bug-602412-dequote-redirect test case, where ResolveByKeep() was called as part of --fix-missing 2025-02-14T18:08:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-11T20:26:10Z urn:sha1:fdc8682db546077cb24b2cc8861b2d5e4eee9da5 The 3.0 solver does not support upgrade arguments to override the policy. 2025-02-14T18:08:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-11T20:21:12Z urn:sha1:175f950685df84395547119f93aa305866d7e36d Our upgrade policy does not support specifying packagenames to upgrade commands that are not subject to the policy. It's possible this can be addressed at a later time, but let's not block the rest of the test from running. 2025-02-14T18:08:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-11T19:23:59Z urn:sha1:2423207431980cb10c085b0890523b1e802c9ab4 We inadvertently performed a global ordering of all possible solutions for the or group using CompareProviders3. This however is not correct, as we lose the ordering of the dependency group *too* much. Mostly this has no effect, but you can see for example in test-explore-or-groups-in-markinstall various instances of it. Adjust said test case to work with the 3.0 solver to the extent possible under the current design. The 3.0 solver does Recommends after processing any manually installed packages; as such the various Recommends test cases do not work: A `Recommends: okay|upgrade` will not upgrade `upgrade` if it visited `upgrade` first. This may change at a future time, but the correct semantics for Recommends are not entirely clear. Notably, the existing solver is not always consistent. You can see here where they matter, but recently I added test-solver-recommends-depends in which the Recommends do not influence the choice of other Depends. 2025-02-14T18:08:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-11T18:08:44Z urn:sha1:ffe2565c36421401550d11990a761d70ac81d208 Phased updates are ignored when strict pinning is on; such that only the installed version will be available. By design of SAT solvers, this means that the version selection clause is unit, and hence the version can be directly propagated, i.e. that choice is safe.