Compare SHA256 to check if versions are really the same
If we know both SHA256, and they're different, the packages are. This
approach stores the SHA256 only at runtime, avoiding the overhead of
storing it on-disk, because when we update repositories we update all
of them anyhow.
Note that pkgCacheGenerator is hidden, so we can just modify its
ABI, hooray.
Closes: #931175
LP: #2029268
(cherry picked from commit 5576e7f76da73f3f5217f90d816cc19b6c0a5a77)
Do not mark updates for install that are still phasing
This fixes an issue where phased updates gain new dependencies
and cause them to be installed despite themselves not being
installed.
In the cause of investigation, it turned out that we also need
to evaluate the candidate version at those early stage rather
than the install version (which is only valid *after* MarkInstall).
This does not fully resolve the problem: If an update pulls in
a phased update, depends are still being installed. Resolving
this while ensuring that phased updates cannot uninstall packages
requires us to do a minimization of changes by trying to keep
back each new install removal and then seeing if any dependency
is being broken by it. This is more complex and will happen
later.
(cherry picked from commit 68ef41ea912f4879b0ee43419c13a3a8c9bfcd22)
dist-upgrade: Revert phased updates using keeps only
In the bug, mutter was kept back due to phasing and the new gnome-shell
depended on that, and was therefore kept back as well, however,
gnome-shell-common was not broken, and apt decided to continue upgrading
it by removing gnome-shell and the ubuntu desktop meta packages.
This is potentially a regression of LP#1990586 where we added keep
back calls to the start of the dist-upgrade to ensure that we do not
mark stuff for upgrade in the first place that depends on phasing
updates, however it was generally allowed by the resolver to also
do those removals.
To fix this, we need to resolve the update normally and then use
ResolveByKeepInternal to keep back any changes broken by held back
packages.
However, doing so breaks test-bug-591882-conkeror because ResolveByKeep
keeps back packages for broken Recommends as well, which is not
something we generally want to do in a dist-upgrade after we already
decided to upgrade it.
To circumvent that issue, extend the pkgProblemResolver to allow
a package to be policy broken, and mark all packages that already
were already going to be policy broken to be allowed to be that,
such that we don't try to undo their installs.
LP: #2025462
(cherry picked from commit 89dd48bdea93849246fc33b447d6d7ad52bb1c4b)
