apt/apt-pkg/solver3.cc, branch 2.9.13Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.9.132024-11-02T12:17:11Zsolver3: 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: Check whether installable versions are allowed2024-11-02T10:44:36ZJulian Andres Klodejulian.klode@canonical.com2024-11-02T10:44:36Zurn:sha1:d7dc72dd8b23f3fbedb32f8cacd9ba920d78ccc3
We only checked if they were still installable, but not if they
were allowed. We should removed the allowed version handling
altogether presumably - we should just mark non-allowed versions
as rejected early on.
solver3: A version selected for install already is allowed.2024-11-02T10:22:45ZJulian Andres Klodejulian.klode@canonical.com2024-11-02T10:22:45Zurn:sha1:6c98593d3e8c99c2c0dfaf18e571e567fc6b5837Add a FIXME around the heap compaction2024-11-02T09:23:15ZJulian Andres Klodejulian.klode@canonical.com2024-08-13T09:47:06Zurn:sha1:88cad6148797c399764333fbae3ade3036eb7dc3
Our work heap is currently cleaned from deeper levels by
removing the entries from the heap and then remaking the
heap which is very inefficient.
We should mark the items as erased instead, and only do
the remove & make_heap dance if we have a lot of erased
entries in there.
Possibly we maybe should use a structure that actually
allows removing entries, that is, an std::set, but
that warrants more investigation on performance aspects.
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: Move needsRescore from Reject to Enqueue()2024-11-02T09:23:15ZJulian Andres Klodejulian.klode@canonical.com2024-08-01T07:08:13Zurn:sha1:835fd787c24c496516965eb59fef81cbd1e304ccsolver3: Remove obsolete checks2024-11-02T09:23:15ZJulian Andres Klodejulian.klode@canonical.com2024-08-01T07:03:15Zurn:sha1:b4f43e48994bec07a9b5aa38d21e3fd350912d16
These checks are no longer needed since Enqueue() ensures the
correctness for us.
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:a5a7b6905dc021d9773229e47ec60367e3e606d8