Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.2 2024-04-17T09:12:58Z 2024-04-17T09:12:58Z David Kalnischkies david@kalnischkies.de 2024-04-17T08:19:40Z urn:sha1:633f6d67a28b375cf1f225f14d3c926e618d46af All other entries in a dependency line get substantial leeway about the amount of spaces surrounding the entry itself and its individual parts, but the very last entry was required to have a version constraint be at least 4 chars long (excluding opening bracket and spaces following it), so if the version is short and a single-char relation used a space had to make up for it. This is a bit unfair in comparison to the other entries who do not have such unreasonable demands, so we reduce our demand to 3 chars or longer, which is satisfied by "=1)". If it is a good idea to hate spaces that much remains unanswered by this commit, but in practice most tools (re)writing the files we parse will include spaces, so its only in files (or on the satisfy command line) directly edited by users that we can encounter such a situation, which is a relatively new development given this line came unchanged from the introduction of this method in 1998. LP: #2061834 2024-03-07T15:35:17Z David Kalnischkies david@kalnischkies.de 2024-01-23T13:45:46Z urn:sha1:3d1614b0a6c9c185ed1b2834e338f14d4de5b124 libapt has a NotEquals relation for version constraints in dependencies, which is used internally e.g. in the MultiArch implementation, but this relation is not supported by Debian policy and as such can not be used in packages. Our parser here is extremely accepting, even unknown relations are parsed as Equals relation – but the version that must match will be a rather strange one… For our own testcases and e.g. on the command line with 'satisfy' it can make sense to have != available… and what strange things apt does parsing unsupported relations is not really much of a concern. Real packages will not have such relations anyhow as we are (mostly) just a consumer, not a producer of packages and index files. 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. 2023-10-04T12:17:16Z Julian Andres Klode julian.klode@canonical.com 2023-10-04T12:17:16Z urn:sha1:b24d6a1f3aff12f32f6a7024aac6961089f99719 This avoids the rabbit hole of md5 on FIPS systems, and repositories have moved to including the value as well. Also stop validating the field, this can be an arbitrary string as far as we are concerned. 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. 2022-04-01T12:16:15Z David Kalnischkies david@kalnischkies.de 2022-03-28T13:25:36Z urn:sha1:7b8da771e2061462b9196f38366c34e4f919d0df dpkg-dev stopped recognizing it in 2007 (1.14.7) while building packages. The rename itself happened in 1995 (0.93.72). 2021-09-04T13:35:15Z David Kalnischkies david@kalnischkies.de 2021-09-04T00:22:24Z urn:sha1:79a675ddf3320bf640d130e592c86fefd1a460e1 What does a M-A:allowed package from non-native/non-foreign architecture provide? If we look at M-A:foreign, such a package satisfies dependencies within its own architecture, but not in other architectures, so the same should apply to :any dependencies on M-A:allowed packages, but we have a problem: While unqualified package names are architecture-specific, the virtual package name qualified with :any is not (see 3addaba1ff). We could of course make it architecture-specific now, but that would introduce many virtual packages for this relatively minor usecase and would reintroduce a need for special display handling. So, we pull a trick here: Barbarian M-A:allowed packages do not provide the architecture-independent :any package anymore, but only a specific one and every :any dependency from a barbarian package is rewritten to an or-group of the specific and the independent :any package. References: 3addaba1ff 2021-06-10T10:58:24Z David Kalnischkies david@kalnischkies.de 2021-06-10T10:58:24Z urn:sha1:7adecd8b2543fc8ee5288b91525a366cf9525cb8 Volatile sources are parsed after the status file, so if we have a version already installed the size information is not stored, so that a reinstall of said version is refused claiming a broken repository. References: 1412cf51403286e9c040f9f86fd4d8306e62aff2 2021-01-27T11:48:58Z Julian Andres Klode julian.klode@canonical.com 2021-01-27T11:31:05Z urn:sha1:ccd952cc8793bc6b866f92912ef0bb51c42eb540 We do download all translations we ever downloaded, but we don't add all of those to the cache, meaning that if we run update with LANG=C, it might still download your de_DE translation, but it won't insert it into the cache, causing your de_DE user to not get translated messages. LP: #1907850 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.