| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We inadvertently considered more upgrades as a better solution in
all cases, but if we are *installing* rather than upgrading, we
should count upgrades as a negative.
Change the code to accomodate that. This requires a few more
tricks:
- We remove the keep count check. This does not appear to work
correctly and would have prevented the fix. We are already
counting all possible changes, so why bother.
- We need to subtract the upgrade count from the install count
(upgrades are a class of installs) since we now allow comparing
solutions with different upgrade counts for install counts.
- After comparing the "new install count", we now compare upgrade
count too, in the opposite direction of upgrading.
To test, we abuse that solver 3.0 does not upgrade all packages
in a source package when using the install command.
LP: #2105395
|
| |
|
|
|
|
| |
The error messages are multi-line now, so need correct escaping.
LP: #2104276
|
| |
|
|
| |
whoopsie does not accept empty values
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Store the solver dumps with zstd compression and base64-encode
them in the crash report; such that they take up significantly
less space and can fit in cassandra's schema.
Base64 is wrapped at 76 characters as the base64 tool does. Do
some magic std::string_view conversion to avoid string copies
for the substr() used to get 76 characters at a time.
Note we can rely on substr(i, 76) to handle less than 76 characters
just fine; it uses std::min(76, size() - i) characters.
|
| |
|
|
| |
These are faster to generate and significantly smaller.
|
| |
|
|
|
|
|
|
|
|
| |
This can provide useful additional context.
To avoid updating the whole test suite for it, introduce a new
option `quiet::NoSolver3Explanation` and set it by default. All
the other tests that assert output will already have matching
tests for --solver 3.0 with the correct messages asserted, it
makes no sense to duplicate them.
|
|
|
Always run the 3.0 solver after the internal solver. If the internal
solver failed, and the 3.0 solver did not, use the 3.0 result.
If 3.0 solver failed or produced a worse result than the internal
solver, write an apport crash dump.
We exclude situations which we now the solver can't handle, i.e.
removals are forbidden and you requested removals, and stuff like
that.
|
