summaryrefslogtreecommitdiff
path: root/cmdline/apt-report-mirror-failure
diff options
context:
space:
mode:
authorDavid Kalnischkies <david@kalnischkies.de>2017-06-04 14:07:09 +0200
committerDavid Kalnischkies <david@kalnischkies.de>2017-06-26 23:31:15 +0200
commitd0eb158be03f15139eee65c4162c9c6e3be10718 (patch)
tree6401c933e7eb1faa283613e80d2875fadf26b4c9 /cmdline/apt-report-mirror-failure
parentfe8c10a39ebc5c42c764516985f000ed8d998c82 (diff)
schedule the correct side of the conflict for removal
In complex situations in which we want to unpack a package which has a conflict/breaks on another package which must be removed due this conflict apt can decide to perform this remove earlier than initially planned. Problem: For three years apt wouldn't remove that package, but the package which has the conflict… The situation isn't very common and easily hidden as the package which is removed is unpacked a few actions later – it becomes visible for packages which protect themselves from removal through like systemd as the running init resulting in upgrade failures (#854041). Note that the package isn't purged, so data shouldn't be lost even if a user runs into a "hidden" case of it as long as the package sticks to the policy of removing data only on purge. Reaching this situation artificially is hard, which is why no testcase is included, as the situation is highly state dependent. Testing with "real" systems indicate that slight modifications in the installed packages set can make the bug not trigger. Regression-Of: 0eb4af9d3d0c524c7afdc684238aa263ac287449 Thanks: Michael Biebl for helping find this with countless tests
Diffstat (limited to 'cmdline/apt-report-mirror-failure')
0 files changed, 0 insertions, 0 deletions