summaryrefslogtreecommitdiff
path: root/test/integration/test-bug-613420-new-garbage-dependency
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2016-09-10 19:52:11 +0200
committerJulian Andres Klode <jak@debian.org>2017-02-22 18:11:10 +0100
commit9bacab3d7ead0246e2894d3a6498e16ee2798f8c (patch)
treeaba13696bd7daf2f9ce7126b7ceca930a6cb310c /test/integration/test-bug-613420-new-garbage-dependency
parent457f110966cf503bd8ad7a290c2d0a42e75548ad (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) (cherry picked from commit 72ea04411b08bb9f25febdc4b4ca8d7b26206f2d) (modified for 1.2.y by adjusting sections in test case)
Diffstat (limited to 'test/integration/test-bug-613420-new-garbage-dependency')
0 files changed, 0 insertions, 0 deletions