apt/apt-pkg/solver3.h, branch 2.9.14Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.9.142024-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: 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.
solver3: Order obsolete choices last2024-06-13T13:10:06ZJulian Andres Klodejulian.klode@canonical.com2024-06-06T09:19:04Zurn:sha1:6708203296911800caf94bb94ce204d3a39af0bd
This has two aspects:
1. For a dependency A | B | C we order the obsolete packages last,
that is, if A is obsolete, this gets reordered to B | C | A,
such that we try to pick non-obsolete packages first to ease
upgrade calculation.
2. When comparing two dependencies, we order dependencies into three
groups: First we satisfy dependencies mentioning only non-installed
(NEW) packages, then we satisfy "normal" dependencies, and finally
we satisfy any dependencies mentioning obsolete packages.
This means for example if you have obsolete libfoo1 and a new
libfoo1t64, that we will see Depends: libfoo1t64 before any
Depends: libfoo1 (which may expand to libfoo1 | libfoo1t64),
so we effectively will have selected "replacement" packages
this way already before getting to older packages where we
would have to choose between the obsolete package and its
replacement.