Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=main 2024-04-26T20:10:30Z 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-19T18:11:22Z Julian Andres Klode julian.klode@canonical.com 2024-01-23T17:37:42Z urn:sha1:3cd6eacd1ab42e414f0d899a3f74fc60140f0e8a We never used the debug level before, so we can do that. This allows us to have the new audit level. We did call DumpErrors() with DEBUG in two debug code paths, so don't touch those. debug 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-22T10:10:24Z Julian Andres Klode julian.klode@canonical.com 2024-03-21T21:18:58Z urn:sha1:c8641c40d1a67408439c3a3a37ea203b838eb21a This reverts commit 9bb953fddae0246a4dcedddb769d75d3521e1f2f. 2024-03-22T10:10:24Z Julian Andres Klode julian.klode@canonical.com 2024-03-21T21:18:08Z urn:sha1:5414789489f9814aaacdc6169975bae1b871a44f The TagFile parser will have already parsed further and can't go back so it needs to reopen the file if compressed. Closes: #1067440 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-20T17:50:14Z Julian Andres Klode julian.klode@canonical.com 2024-02-20T08:56:06Z urn:sha1:e2949fc463f9e087978b072c82b11860ee02fdb6 This adds a bit more code but avoids any surprises later on by having both the shadowed and non-shadowed meta index in the list. Gbp-Dch: ignore 2024-02-20T17:50:14Z Julian Andres Klode julian.klode@canonical.com 2024-02-19T11:07:55Z urn:sha1:b6274188312e6338e94edc45dbf9cc410d650477 Convert sources.list Snapshot option from opt-in to automatic. If we can find a snapshot server, Snapshot: yes is assumed if a snapshot is specified. On the implementation side, we record automatic snapshot enablement by adding a '?' suffix to the snapshot timestamp, if any is specified, this avoids introducing bugs into the code where we could end up with an empty snapshot. This has an annoying internal implementation caveat: Since we call GetDebReleaseIndexBy() with the SHADOWED option emplaced, if we do not find a server, we need to remove the SHADOWED option again, but we already have inserted a shadowed release index into the list. This will simply insert the release index a second time without the SHADOWED option which in preliminary testing works fine, but it would arguably be more correct to also remove the release index again if we have created it. FIXME: This only has one test case: A source with supported snapshot server is auto-discovered. We should also add a test case where we cannot detect a server and then don't fail in automatic mode. 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.