Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.24 2025-01-05T18:29:47Z 2025-01-05T18:29:47Z Julian Andres Klode julian.klode@canonical.com 2025-01-05T18:29:47Z urn:sha1:cf0257b4d2f559a914fcafa58e5819f624dc8599 There were some references to APT::StringView that don't make much sense anymore. 2024-11-28T08:03:02Z Julian Andres Klode jak@debian.org 2024-11-28T08:03:02Z urn:sha1:edf03432568598dec12dfd242e6a4ed03a881693 The version that accepted APT::StringView was marked public. 2024-11-14T18:08:42Z наб nabijaczleweli@nabijaczleweli.xyz 2024-11-14T18:08:42Z urn:sha1:fdd846cd67def08f04cc616530adc144fc5435d7 2024-11-12T19:36:21Z наб nabijaczleweli@nabijaczleweli.xyz 2024-11-12T16:59:18Z urn:sha1:e26c9290145da39beeabf5769e61eb38ab2cce78 2024-11-12T19:36:20Z наб nabijaczleweli@nabijaczleweli.xyz 2024-11-12T16:59:23Z urn:sha1:e900ad1a727912b340aa43417bff895294854d3b 2024-11-12T19:36:16Z наб nabijaczleweli@nabijaczleweli.xyz 2024-11-12T16:59:21Z urn:sha1:982998a061461a503352d85b1d0a76a99c8480cd 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.