Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=main 2026-01-05T21:20:24Z 2026-01-05T21:20:24Z Julian Andres Klode jak@debian.org 2025-12-28T15:56:28Z urn:sha1:21d099878ed8c34f3b13747bcec380e0402e57a3 The previous use of decision here conflicted with the use of decision level and the general notion of having made a decision, because the assignment might have been propagated as a matter of fact. 2025-10-26T07:28:08Z Julian Andres Klode jak@debian.org 2025-10-26T07:24:39Z urn:sha1:5e8e69cdd6b512480f3208298725e1e44c80f06e Not needed so far because we export a default 3.0 APT_SOLVER, but quite useful if we stop doing so (next commit). 2025-03-08T22:18:05Z Julian Andres Klode julian.klode@canonical.com 2025-03-06T19:07:30Z urn:sha1:3967b75ae4a10d0d79560dfecb8eb210aad4f4f2 Introduce a new function, LongWhyStr() that returns a longer reason for why something is being installed (or not). This does the same path walk as the other function does, but it renders the clauses at each level, and one per line, so the whole output is a lot more informative. It is a separate function to keep the existing debug messages use the simple single line implication graph We remove the other special case in AddWork() for empty solutions to mke use of the general case in Solve() instead, and then adapt the case in Solve() to the same case as in Enqueue(). This also happens to fix the bug that when we encountered an empty clause we just printed the clause had no solution, but not how we got to install the package with the clause. Adapt the test suite for the changes which is an annoying amount of paperwork. 2025-02-14T18:08:45Z Julian Andres Klode julian.klode@canonical.com 2025-02-05T19:37:12Z urn:sha1:943562a4ed2ddc80b84466d85e821037937f8b5c Dependencies shared by all versions are enqueued at the package level, so avoid enqueuing duplicates at the version level. This presumably has no meaningful impact on performance, potentially a negative performance impact on some workloads as we now need to find the duplicates again; it can become useful when there is a lot of backtracking. More importantly though this improves error messages, because now we can say that "all versions of foo depend on X", rather than saying "foo=1 depends on X" and you are left wondering why we did not select "foo=2". In this commit though, improved error messages are not implemented, they depend on redesigning the reason tracking to use clauses. Also the rationale tracking includes a lot more dependencies of the form "pkg:arch=version -> pkg:arch" which are annoying. Improved error messages should fold them into one node. 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. 2021-06-10T14:38:09Z David Kalnischkies david@kalnischkies.de 2021-06-10T14:38:09Z urn:sha1:18140e1db1c386a8c6da004956ae8a96152de4d1 Temporary hacks should be temporary, especially if they hide bugs. After fixing one in the previous commit this is just busy work to add download information to the places which check that output. Gbp-Dch: Ignore 2021-04-25T14:25:57Z David Kalnischkies david@kalnischkies.de 2021-03-06T13:12:01Z urn:sha1:f90b892e6acc0ca725811ef0dd9be3fed66c444f If a first step of the solver can figure out that a package is uninstallable it might reset the candidate so that later steps are prevented from exploring this dead end. While that helps the resolver it can confuse the display of the found solution as this will include an incorrect count of packages not upgraded in this solution. It was possible before, but happens a fair bit more with the April/May resolver changes last year so finally doing proper counting is a good idea. Sadly this is a bit harder than just getting the number first and than subtracting the packages we upgraded from it as the user can influence candidates via the command line and a package which could be upgraded, but is removed instead shouldn't count as not upgraded as we clearly did something with it. So we keep a list of packages instead of a number which also help in the upgrade cmds as those want to show the list. Closes: #981535 2020-05-23T15:58:42Z David Kalnischkies david@kalnischkies.de 2020-05-22T16:56:40Z urn:sha1:04a020d7a217d6b5af86c048c2974760053b8079 For a (partially) installed package like the one MarkInstall operates on at the moment we want to discard the candidate from, we have to first remove the package from the internal state keeping to have proper broken counts and such and only then reset the candidate version which is a trivial operation in comparison. Take a look at the testcase: Now, what is the problem? Correct, git:i386. Didn't see that coming, right? It is M-A:foreign so apt tries to switch the architecture of git here (which is pointless, it knows that this won't work, but lets fix that in another commit) will eventually realize that it can't install it and wants to discard the candidate of git:i386 first removing the broken indication like it should, removing the install flag and then reapplies the broken indication: Expect it doesn't as it wants to do that over the candidate version which the package no longer had so seemingly nothing is broken. It is a bit of a hairball to figure out which commit it is exactly that is wrong here as they are all influencing each other a bit, but >= 2.1 is an acceptable ballpark. Bisect says 57df273 but that is mostly a lie. Closes: #961266 2020-05-18T13:55:36Z David Kalnischkies david@kalnischkies.de 2020-05-17T23:03:52Z urn:sha1:1f641cf70e9cd52c093b4b62dc392f29cf34f03e Turns out that pkgDepCache and pkgProblemResolver maintain two (semi) independent sets of protected flags – except that a package if marked protected in the pkgProblemResolver is automatically also marked in the pkgDepCache as protected. This way the pkgProblemResolver will have as protected only the direct user requests while pkgDepCache will (hopefully) propagate the flag to unavoidable dependencies of these requests nowadays. The pkgProblemResolver was only checking his own protected flag though and based on that calls our Mark* methods usually without checking return, leading to it believing it could e.g. remove packages it actually can't remove as pkgDepCache will not allow it as it is marked as protected there. Teaching it to check for the flag in the pkgDepCache instead avoids it believing in the wrong things eventually giving up. The scoring is keeping the behaviour of adding the large score boost only for the direct user requests though as there is no telling which other sideeffects this might have if too many packages get too many points from the get-go. Second part of fixing #960705, now with pkgProblemResolver output which looks more like the whole class of problem is resolved rather than a teeny tiny edgecase it was before. 2020-05-18T13:55:36Z David Kalnischkies david@kalnischkies.de 2020-05-15T14:44:49Z urn:sha1:65ce0eb3c0d71031c59c14c7e433b0b969548978 We exit early from installing dependencies of a package only if it is not a user request to avoid polluting the state with installs which might not be needed (or detrimental even) for alternative choices. We do continue with installing dependencies though if it is a user request as it will improve error reporting for apt and can even help aptitude not hang itself so much as we trim the problem space down for its resolver dealing with all the easy things. Similar things can be said about the testcase I have short-circuit previously… keep going test, do what you should do to report errors!