| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If a package is already pinned to a negative value, we should not
override this with a positive 1. This causes packages to be installable
that were pinned to -1, which is not intended.
For this, implement phasing as a ceiling of 1 for the pin instead
of a fixed 1 value. An alternative would have been to fix it to
NEVER_PIN, but that would mean entirely NEW packages would not be
installable while phasing which is not the intention either.
LP: #1978125
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a package is not installed yet, we do need to apply
phasing as we otherwise get into weird situations when
installing packages:
In the launchpad bug below, ubuntu-release-upgrader-core
was installed, and hence the phasing for the upgrade to it
was applied. However, ubuntu-release-upgrader-gtk was about
to be installed - and hence the phasing did not apply, causing
a version mismatch, because ubuntu-release-upgrader-gtk from
-updates was used, but -core from release pocket. Sigh.
An alternative approach to dealing with this issue could be to
apply phasing to all packages within the same source package,
which would work in most cases. However, there might be unforeseen
side effects and it is of course possible to have = depends between
source packages, such as -signed packages on the unsigned ones for
bootloaders.
This problem does not occur in the update-manager implementation
of phased updates as update-manager only deals with upgrading packages,
but does not install new packages and thus does not see that issue. APT
however, has to apply phasing more broadly, as you can and often do
install additional packages during upgrade, or upgrade packages during
install commands, as both accept package list arguments and have the
same code in the backend.
LP: #1925745
|
|
|
This adds support for Phased-Update-Percentage by pinning
upgrades that are not to be installed down to 1.
The output of policy has been changed to add the level of
phasing, and documentation has been improved to document
how phased updates work.
The patch detects if it is running in a chroot, and if so, always
includes phased updates, restoring classic apt behavior to avoid
behavioral changes on buildd chroots.
Various options are added to control this all:
* APT::Get::{Always,Never}-Include-Phased-Updates and their legacy
update-manager equivalents to always or never include phased updates
* APT::Machine-ID can be set to a UUID string to have all machines in a
fleet phase the same
* Dir::Etc::Machine-ID is weird in that it's default is sort of like
../machine-id, but not really, as ../machine-id would look up
$PWD/../machine-id and not relative to Dir::Etc; but it allows you to
override the path to machine-id (as opposed to the value)
* Dir::Bin::ischroot is the path to the ischroot(1) binary which is used
to detect whether we are running in a chroot.
|
