[Impact]
* Without the introduced fallbacks u-u could not upgrade particular package sets from -security. It could be observed in Cosmic with systemd security updates failing to install in:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/u/unattended-upgrades/20190318_182031_fe4fe@/log.gz
[Test Case]
* The fix includes the extension of the build-time test cases to cover package sets with which u-u fails with without the fallback:
Running ./test_rewind.py with python3
DEBUG:root:APT::VersionedKernelPackages is not set
DEBUG:root:adjusting candidate version: test-package=2.0
DEBUG:root:adjusting candidate version: test2-package=2.0
DEBUG:root:falling back to marking test2-package, then adjusting changes
DEBUG:root:adjusting candidate version: test2-package-dependency=2.0
DEBUG:root:adjusting candidate version: test2-package=2.0
DEBUG:root:adjusting candidate version: test3-package=2.0
DEBUG:root:adjusting candidate version: test-package=2.0
DEBUG:root:falling back to marking test3-package, then adjusting changes
WARNING:root:package test3-package upgradable but fails to be marked for upgrade (E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.)
DEBUG:root:falling back to adjusting all packages
DEBUG:root:adjusting candidate version: test-package=2.0
DEBUG:root:adjusting candidate version: test2-package=2.0
DEBUG:root:adjusting candidate version: test2-package-dependency=2.0
DEBUG:root:adjusting candidate version: test3-old-package-dependency=2.0
DEBUG:root:adjusting candidate version: test3-package=2.0
WARNING:root:package z-package upgradable but fails to be marked for upgrade ()
.
----------------------------------------------------------------------
Ran 1 test in 0.039s
OK
[Regression Potential]
* When failing to mark a package to upgrade/install from the allowed origin holding the highest version the first fallback resets all already adjusted candidates to the highest available version irrespective to the origin of this version being allowed or not. This itself is not a risky operation and sanity checks later ensure that no package would be installed from not allowed origins but it can trigger code paths in apt that were not tried before and may crash.
* In testing apt's resolver failed to find a solution for upgrading packages with the first fallback raising an error, but the second fallback handles the error and tries adjusting _all_ potentially upgradable/installable package at the expense of using much more CPU time. This second fallback is not expected to be reached often (it is not reached in autopkgtests either) and adjusting all of those packages matches an earlier behavior of u-u, thus the slow-down may not be considered a regression.
[Other Info]
* If the second fallback is found to be reached often a different fallback can be introduced before the first one, to adjust all packages from the same source package then try again:
See: https://github.com/mvo5/unattended-upgrades/pull/175#discussion_r268226796
This bug was fixed in the package unattended-upgrades - 1.10ubuntu2
---------------
unattended-upgrades (1.10ubuntu2) disco; urgency=medium
* Compare apt.package.Version objects and not the versions' string
representation. (LP: #1820888)
This prevented adjusting candidates when the strings sorted differently.
Also extend tests to catch issue.
* Fall back to adjusting more packages' candidates
when a package from an allowed origin can't be marked to install/upgrade.
(LP: #1821101)
* Skip sending email when no package had to be installed, upgraded or removed
(LP: #1821103) (Closes: #924554)
-- Balint Reczey <email address hidden> Fri, 22 Mar 2019 20:42:08 +0100