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-24T13:16:21Z David Kalnischkies david@kalnischkies.de 2024-04-04T13:36:24Z urn:sha1:7a1063e81b855ac7ff9ee54f115843c3af6dd1bf Our code does the right thing currently, so lets add a test to ensure this keeps being the case in the future. 2024-04-24T13:16:21Z David Kalnischkies david@kalnischkies.de 2024-04-23T16:13:46Z urn:sha1:9c06578c37ff77b70b9d978d48528df13e13530f Our autoremoval-advertisment is modified by SUDO_USER as if the current apt call was made with sudo it seems a good idea to show the ad with sudo as well. That is annoying for our tests through as normally the tests are run locally or by autopkgtest without sudo, but in Gitlab CI we use it (to run our tests as user… as we are already root) and so individual tests had to deal with this. That is annoying and really not needed as we can have our autoremove test check that this ad gets displayed the right way and ignore it the rest of the time. 2024-04-24T13:16:21Z David Kalnischkies david@kalnischkies.de 2024-03-14T20:59:10Z urn:sha1:d030a1041b243c45dcd41e34d3c2b21cf1a533ba We schedule reverse dependencies for an upgrade, but we shouldn't do it if we have ear-marked this package for removal later on. Usually the solver will end up doing the right thing like it already did in the included testcase in the end, but given that before it reaches the right end it explored a bad path which can lead to more installs and removals influencing later decisions or are just too hard for the resolver to undo later on, we can just not explore this path to begin with. References: e077370ffcb3669a50a600e80356c2002e6b176d 2024-04-24T13:16:21Z David Kalnischkies david@kalnischkies.de 2024-04-03T19:12:01Z urn:sha1:e099ee946000797f4c03b8c5075ce7ebba193337 We remove new garbage packages from the solution if we can as installing a new package which is at the same time considered garbage looks silly, but it could also be a new dependency of another garbage package, so we have a second round trying to save such packages. In this round we weren't considering versioned constraints on dependency relations through so even an unsatisfied old recommends could save which it shouldn't. 2024-04-20T12:15:47Z Julian Andres Klode julian.klode@canonical.com 2024-04-20T12:09:37Z urn:sha1:4e9a9dbf9bd52d38ab5818f3eb32c8189fd25671 GTest has a lot of broken things with signed vs unsigned, and double integer promotions, let's silence them. 2024-04-20T12:15:47Z Julian Andres Klode julian.klode@canonical.com 2024-04-20T11:45:55Z urn:sha1:1350ca686ba2557dd8e2c17eab367bfbfe9b389a This avoids us polluting the configuration for later tests, since the test order apparently is not deterministic. We probably should fix some common test case thingy instead. 2024-04-19T14:58:24Z Julian Andres Klode julian.klode@canonical.com 2024-04-19T13:57:23Z urn:sha1:58ee0fabc9028fcdf86faab3bb9c1db2b27e3644 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-04-13T21:59:41Z Julian Andres Klode jak@debian.org 2024-04-13T21:59:41Z urn:sha1:ac8fe4b030754584cda9cb1707fc3d9f0d792366 This produces a much more appealing progress bar and it can even show parts of the progress being done.