Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.1 2024-02-20T12:49:04Z 2024-02-20T12:49:04Z Julian Andres Klode julian.klode@canonical.com 2024-02-20T12:43:08Z urn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49 This was automated with sed and git-clang-format, and then I had to fix up the top of policy.cc by hand as git-clang-format accidentally indented it by two spaces. 2022-09-02T14:55:45Z David Kalnischkies david@kalnischkies.de 2022-09-01T13:14:52Z urn:sha1:f52c1ce9b31befb71016a20759b96b4946034fcb Not having a dpkg/status file used to be a hard error which from a boostrap perspective is suspect as in the beginning, there is no status so you would need to touch it into existence. We make a difference between factual non-existence and inaccessibility to catch mistakes in which the file is not readable for some reason, the testcase test-bug-254770-segfault-if-cache-not-buildable is an example of this. Note that apt has already figured out at this point that this is a Debian-like system which should have a dpkg/status file. This change does not effect the auto-detection and is not supposed to. 2022-06-28T12:54:42Z Julian Andres Klode julian.klode@canonical.com 2022-06-28T12:53:14Z urn:sha1:20739359fa936c0851a4c0f37667526d98c22761 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 2022-06-28T12:25:18Z Julian Andres Klode julian.klode@canonical.com 2022-06-24T14:09:24Z urn: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 2022-04-01T12:16:19Z David Kalnischkies david@kalnischkies.de 2022-04-01T11:45:09Z urn:sha1:472376be6818b5ea43250abcbecfcab53b4a729a The speed critical paths were converted earlier, but the remaining could benefit a tiny bit from this as well especially as we have the facility now available and can therefore brush up the code in various places in the process as well. Also takes the time to add the hidden Exists method advertised in the headers, but previously not implemented. 2021-11-27T10:22:38Z Ville Skyttä ville.skytta@iki.fi 2021-11-03T22:08:07Z urn:sha1:01eed4234440d82fc52c8186cf4268517bcd28bc 2021-05-17T08:25:28Z Julian Andres Klode julian.klode@canonical.com 2021-05-17T08:25:28Z urn:sha1:81eb944c76d99f34b57d7c3efd283c3ffb6e4c1f 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 2021-01-08T13:48:47Z Julian Andres Klode julian.klode@canonical.com 2021-01-08T13:43:21Z urn:sha1:bd64bb79537fac17e1474672402d6b0572dce94a If we have different binNMU versions on different architectures, we don't want madness to ensue. This is a change from how update-manager does things, as Ubuntu does not have binNMUs, but I believe it's the right thing to do for a generic solution. 2021-01-08T13:48:47Z Julian Andres Klode julian.klode@canonical.com 2020-08-10T18:16:11Z urn:sha1:c5bc86d45e003905ef411146e66b414d26fb1ff8 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. 2020-04-26T16:19:43Z David Kalnischkies david@kalnischkies.de 2020-04-26T16:19:43Z urn:sha1:9064a832bf2f02e2fd26c62ee867dd779797235a Reported-By: gcc -Wuseless-cast Gbp-Dch: Ignore