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

1 files changed, 1 insertions, 1 deletions

diff --git a/apt-pkg/packagemanager.cc b/apt-pkg/packagemanager.cc
index a8537431b..85ac5f9da 100644
--- a/apt-pkg/packagemanager.cc
+++ b/apt-pkg/packagemanager.cc
@@ -937,7 +937,7 @@ bool pkgPackageManager::SmartUnPack(PkgIterator Pkg, bool const Immediate, int c
 		  if (Debug)
 		     clog << OutputInDepth(Depth) << "Removing " << ConflictPkg.FullName() << " now to avoid " << APT::PrettyDep(&Cache, End) << endl;
 		  // no earlyremove() here as user has already agreed to the permanent removal
-		  if (SmartRemove(Pkg) == false)
+		  if (SmartRemove(ConflictPkg) == false)
 		     return _error->Error("Internal Error, Could not early remove %s (%d)",ConflictPkg.FullName().c_str(), 1);
 	       }
 	    }