Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.5 2024-05-16T22:15:26Z 2024-05-16T22:15:26Z David Kalnischkies david@kalnischkies.de 2024-05-16T22:15:26Z urn:sha1:3347b7a00682a0498a2602ce3e4e72c2c3d49c75 Another instance of our parser written for sane clean input, but nowadays used also for user-provided input which can contain very many strange formatting and especially white spaces all over the place. Closes: #1071219 2024-04-26T20:10:30Z David Kalnischkies david@kalnischkies.de 2024-04-26T18:50:49Z urn:sha1:c98bcdf00e5366fec101dd17094d36be21872a02 If dpkg-gencontrol was involved in the creation of a package we will not usually encounter empty or otherwise useless fields, but apparently not everyone is using it. It isn't recommended to have these empty lines, but it isn't too hard to ignore for Provides as we did for dependencies already and apt-ftparchive can be convinced to produce empty files (if you feed it such a package) as well, so lets be nice and provide users with a more accepting parser. Closes: #1069874 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