apt/test/integration/test-phased-updates-upgrade, branch mainDebians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=main2025-02-14T18:08:45ZFix test-phased-updates-upgrade2025-02-14T18:08:45ZJulian Andres Klodejulian.klode@canonical.com2025-02-11T20:21:12Zurn:sha1:175f950685df84395547119f93aa305866d7e36d
Our upgrade policy does not support specifying packagenames to
upgrade commands that are not subject to the policy. It's possible
this can be addressed at a later time, but let's not block the rest
of the test from running.
Show a separate list of upgrades deferred due to phasing2024-02-13T14:08:57ZJulian Andres Klodejulian.klode@canonical.com2024-02-13T11:54:07Zurn:sha1:1a0882558da05eaf471c2b4049ae27305e7c70ec
This introduces a new line:
The following upgrades have been deferred due to phasing
This is any kept back package that is also phasing. This may
not be 100% accurate as we have kept it back due to other reasons
in an install command, for example, but we don't track for which
packages we applied phasing in reality.
If additional packages are kept back that are not phasing, show
a a notice
"N: Some packages may have been kept back due to phasing."
LP: #1988819
Add the ?security pattern2024-02-13T13:28:06ZJulian Andres Klodejulian.klode@canonical.com2024-02-13T11:33:51Zurn:sha1:82f4cfc971ef6a2e56b34227d9e0b1a594dc2265Add a new ?phasing pattern2024-02-13T13:28:06ZJulian Andres Klodejulian.klode@canonical.com2024-02-13T11:29:28Zurn:sha1:422e68f569f374f697b84332f7e68c6fe5f7389f
This selects all packages that are being kept back due to phasing
on your system.
For phasing, check if current version is a security update, not just previous ones2024-02-13T13:13:56ZJulian Andres Klodejulian.klode@canonical.com2024-02-13T12:58:40Zurn:sha1:26e0e9b76fb06afe5250eeb8e5b3d069d4793432
We only considered an update a security update if a previous update
is a security update but not the update in question itself.
LP: #2051181
Check state of dependency, not dependee in dependency keep back2022-09-28T14:32:44ZJulian Andres Klodejulian.klode@canonical.com2022-09-26T10:33:55Zurn:sha1:f93a5aa2daa92255c75865b6f92dddb4b072ff33
When iterating over I's dependencies (which are called Pkg), we
accidentally checked if I was Protected() instead of Pkg when deciding
whether Pkg can be kept back.
LP: #1990684
test-phased-updates-upgrade: Tests with arguments2022-06-30T11:21:19ZJulian Andres Klodejulian.klode@canonical.com2022-06-30T11:20:45Zurn:sha1:8416bcb58cba0f8b5e8e8d26b71ae838f228111d
Pass some package names to upgrade to see that that works
Gbp-Dch: ignore
(Temporarily) Rewrite phased updates using a keep-back approach2022-06-28T12:25:18ZJulian Andres Klodejulian.klode@canonical.com2022-06-24T14:09:24Zurn:sha1:db131677bee45c86031d37d7b451e6ece692efb2
This is a lot closer to the original implementation in update-manager,
but still has a couple of differences that might cause bugs:
- When checking whether a version is a security update, we only
check versions in between and not any later version. This happens
mostly because we do not know the suite, so we just check if there
is any version between the installed version and our target that
is a security update
- We only keep already installed packages, as we run before the
resolver. update-manager first runs the resolver, and then marks
for keep all packages that were upgraded or newly installed that
are phasing (afaict).
This approach has a significant caveat that if you have version 1
installed from a release pocket, version 2 is in security, and version
3 is phasing in updates, that it installs version 3 rather than 2
from security as the policy based implementation does.
It also means that apt install does not respect phasing and would
always install version 3 in such a scenario.
LP: #1979244