apt/apt-pkg/solver3.h, branch 2.9.23Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.9.232024-12-03T08:44:18Zsolver3: Reject all non-candidates outright for strict pinning2024-12-03T08:44:18ZJulian Andres Klodejulian.klode@canonical.com2024-11-02T11:45:07Zurn:sha1:8f317d97c9fb821e839342ae445c824207678eb7
Reimplement strict pinning by rejecting the non-candidates when
translating the problem from the depcache to the solver. This is
substantially better than restricting the list of alternatives for
an or group to only include allowed ones for debugging purposes,
albeit a bit slower.
solver3: Refactor Install(Ver) to PropagateInstall(Ver)2024-11-02T12:17:11ZJulian Andres Klodejulian.klode@canonical.com2024-11-02T12:13:51Zurn:sha1:9f40a9a3251cc6b51bc50a5fe12c49a45a51aedd
This is the first part of changing from Install() to Enqueue() for
installs, affecting only the versions. For packages, we still have
to resolve the group changing: When propagating cleanly, we don't
have the information as to which group the package was part of,
hence we are no longer able to queue the version selection of
upgrades before obsolete packages, for example, which needs
solving.
solver3: Rename the 'dirty' bit to 'erased'2024-11-02T09:23:15ZJulian Andres Klodejulian.klode@canonical.com2024-08-01T08:08:42Zurn:sha1:9d99322c14c44d73722bd580473abf67538b7c05
This captures the meaning better
solver3: Remove the Reject() function, propagate in Enqueue() instead2024-11-02T09:23:15ZJulian Andres Klodejulian.klode@canonical.com2024-08-01T07:57:28Zurn:sha1:cab40edc4040691fcadbddbdee77decf4bf20573
Long term we should have a propagate queue, this is the minimal change
to keep the behavior identical, a first step on the road.
solver3: Introduce new Assume() and Enqueue() helpers and use them2024-11-02T09:23:15ZJulian Andres Klodejulian.klode@canonical.com2024-08-01T06:51:37Zurn: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.
solver3: Rename Reason to Var2024-11-02T09:23:15ZJulian Andres Klodejulian.klode@canonical.com2024-08-01T05:25:25Zurn:sha1:a5a7b6905dc021d9773229e47ec60367e3e606d8solver3: Track all assignments and undo them individually2024-11-02T09:23:15ZJulian Andres Klodejulian.klode@canonical.com2024-08-01T03:43:09Zurn:sha1:761fc96fe6158d46f11137c14822545ac0b0fe91
Adopt MiniSAT's strategy for dealing with assignments and choices,
having a single step undoOne() function to undo one and record them
all on the queue; this should likely speed up backtracking since we
no longer need to rescan everything.
Fix obsoleted-by handling for experimental2024-08-12T14:05:54ZJulian Andres Klodejulian.klode@canonical.com2024-08-12T13:27:31Zurn:sha1:5d2c0e600656db690aaeb0768f3df8e71127808a
Basically this boils down to checking that the priority of the
source candidate candidate is higher or equal than the priority
of the package's candidate that is being under consideration.
It stands to reason if we maybe we should actually calculate a
source candidate version; this will look similar but may perhaps
perform slightly different.
solver3: Refactor Reason.Pkg()/Reason.Ver() use with iterator2024-07-16T11:55:07ZJulian Andres Klodejulian.klode@canonical.com2024-07-16T11:54:11Zurn:sha1:62573e3ca6b45b0d12b9be8b02da116ce0d91b75
More code but nicer to read
solver3: Consider packages as obsolete and not versions2024-07-02T18:08:38ZJulian Andres Klodejulian.klode@canonical.com2024-07-02T16:51:11Zurn:sha1:8c13d9cb1c38ebb52cf6e1c8c7561c5c5d87c970
This makes more sense, as all package versions are obsolete that
are not the candidate, usually.
Pay special attention to no-strict-pinning: If we don't have
strict pinning, a package without a candidate version may still
be non-obsolete if the latest version is not obsolete.
Likewise, in no-strict-pinning any later source version that exists
will cause the package to be considered obsolete, rather than just
candidates.