diff options
| author | David Kalnischkies <david@kalnischkies.de> | 2016-09-10 19:52:11 +0200 |
|---|---|---|
| committer | Julian Andres Klode <jak@debian.org> | 2017-02-22 16:08:22 +0100 |
| commit | 72ea04411b08bb9f25febdc4b4ca8d7b26206f2d (patch) | |
| tree | 79c4091dac3a1ca442eccf720560782b0e11b885 /test/integration/Packages-bug-590438-broken-provides-thanks-to-remove-order | |
| parent | 15f32c417545d6e19d459004d510b7101bf6683f (diff) | |
don't install new deps of candidates for kept back pkgs
In effect this is an extension of the 6 years old commit
a8dfff90aa740889eb99d00fde5d70908d9fd88a which uses the autoremover to
remove packages again from the solution which are no longer needed to be
there. Commonly these are dependencies of packages we end up not
installed due to problem resolver decisions. Slightly less common is
the situation we deal with here: a package which we wanted to upgrade
sporting a new dependency, but ended up holding back.
The problem is that all versions of an installed reverse dependencies can
bring back a "garbage" package – we need to do this as there is
nothing inherently wrong in having garbage packages installed or upgrade
them, which itself would have garbage dependencies, so just blindly
killing all new garbage packages would prevent the upgrade (and actually
generate errors). What we should be doing is looking only at the version
we will have on the system, disregarding all old/new reverse dependencies.
Reported-By: Stuart Prescott (themill) on IRC
(cherry picked from commit 952171787a0b865c17d5c9476e272106383ae93a)
Diffstat (limited to 'test/integration/Packages-bug-590438-broken-provides-thanks-to-remove-order')
0 files changed, 0 insertions, 0 deletions