apt/test/integration/test-resolve-by-keep-new-recommends, branch mainDebians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=main2025-03-12T17:54:25Zsolver3: Fix test-resolve-by-keep-new-recommend2025-03-12T17:54:25ZJulian Andres Klodejulian.klode@canonical.com2025-03-12T17:47:55Zurn:sha1:460753f991ca42c3c4a5ed494038db76c55e2a08
Reorder the if branches a bit to simplify the understanding
of the promotions, and allow us to keep track of which
dependency existed in the installed version.
Change the rule for promoting new recommends to only promote
new recommends to depends in *upgrade* and not *dist-upgrade*
per the test-resolve-by-keep-new-recommends test case.
This makes some sense: In a dist-upgrade, the solver could
otherwise decide to remove an installed package if both the
following hold:
(1) something needs the upgraded version | something else
(2) the upgraded version is not installable due to unsat recommends
tests: support spaces in path and TMPDIR2015-12-19T22:04:34ZDavid Kalnischkiesdavid@kalnischkies.de2015-12-15T16:20:26Zurn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2
This doesn't allow all tests to run cleanly, but it at least allows to
write tests which could run successfully in such environments.
Git-Dch: Ignore
test exitcode as well as string equality2015-03-16T17:01:54ZDavid Kalnischkiesdavid@kalnischkies.de2015-03-09T23:59:44Zurn:sha1:25b86db159fbc3c043628e285c0c1ef24dec2c6e
We use test{success,failure} now all over the place in the framework, so
its only consequencial to do this in the situations in which we test for
a specific output as well.
Git-Dch: Ignore
fix progress output for (dist-)upgrade calculation2014-09-26T22:10:05ZDavid Kalnischkiesdavid@kalnischkies.de2014-08-17T10:30:21Zurn:sha1:2a884c612b10b27f4be2cc6dd689bfe448d9361a
Previously, we had a start and a done of the calculation printed by
higher-level code, but this got intermixed by progress reporting from an
external solver or the output of autoremove code…
The higherlevel code is now only responsible for instantiating a
progress object of its choosing (if it wants progress after all) and the
rest will be handled by the upgrade code. Either it is used to show the
progress of the external solver or the internal solver will give some
hints about its overall progress. The later isn't really a proper
progress as it will jump forward after each substep, but that is at
least a bit better than before without any progress indication.
Fixes also the 'strange' non-display of this progress line in -q=1, while
all others are shown, which is reflected by all testcase changes.
make ResolveByKeep() more clever and hold back packages that would go into a broken policy state by the upgrade2011-07-14T09:03:55ZMichael Vogtmichael.vogt@ubuntu.com2011-07-14T09:03:55Zurn:sha1:953b348cb02fcdccb597b6988f904bfdb696e92e