Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.0 2024-02-20T12:49:04Z 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. 2021-11-27T10:22:38Z Ville Skyttä ville.skytta@iki.fi 2021-11-03T22:08:07Z urn:sha1:01eed4234440d82fc52c8186cf4268517bcd28bc 2021-04-23T15:13:55Z Julian Andres Klode julian.klode@canonical.com 2021-04-23T15:06:40Z urn:sha1:a7f2152f0ce46322791f0574d76aadfdfbde6bec dpkg 1.20.8 also made --force-remove-essential optional for deconfiguring essential packages, so let's do this. Also extend the test case to make sure we actuall pass auto-deconfigure and do not make any --remove calls, or pass --force-remove to dpkg. 2021-03-01T20:43:54Z Julian Andres Klode julian.klode@canonical.com 2021-03-01T20:43:03Z urn:sha1:0d51cf142884801c903df0cddaec5545f0174553 Conflicts do require removing the package temporarily, so they really should not be used. We need to improve that eventually such that we can deconfigure packages when we have to remove their dependencies due to conflicts. 2021-02-23T18:10:29Z Julian Andres Klode julian.klode@canonical.com 2021-02-23T17:23:30Z urn:sha1:f8ff3afcd42d8b2e6506bc6f44a894149bf87442 dpkg will be changed in 1.20.8 to not require --force-remove for deconfiguration anymore, but we want to decouple our changes from the dpkg ones, so let's always pass --force-remove-protected when installing packages such that we can deconfigure protected packages. Closes: #983014 2021-01-08T11:38:23Z Julian Andres Klode julian.klode@canonical.com 2021-01-08T11:36:31Z urn:sha1:c530a192d6a57e091d400cb42f9ce0d5a327ff01 The benefits of immediate configuration are that Essential packages will be configured immediately, so if they are wrongly not working without being configured they won't fail later packages. However, we've reached the point where dependencies on the essential set are too complex for immediate configuration to always work, causing installations to error out at the end, despite having succeeded, because we did not correctly return the error here and did not check for pending errors before running dpkg. Given that we check and configure any packages at the end that have not been configured yet, or fail if we can't configure them; making immediate configuration optional is the best way forward - it orders as it does now, but then does not spuriously fail after having successfully installed everything. Closes: #973305, #188161, #211075, #649588 LP: #1871268 2020-11-06T09:51:06Z Julian Andres Klode julian.klode@canonical.com 2020-10-08T09:50:19Z urn:sha1:2b13473a9b9947f55a0871d146e4fee456b0af60 In LP#835625, it was reported that apt did not unpack multi-arch packages in the correct order, and dpkg did not like that. The fix also made apt configure packages together, which is not strictly necessary. This turned out to cause issues now, because of dependencies on libc6:i386 that caused immediate configuration of that to not work. Work around the issue by not configuring multi-arch: same packages in lockstep if they have the immediate flag set. This will be the pseudo-essential set, and given how essential works, we mostly need the native arch to work correctly anyway. LP: #1871268 Regression-Of: 30426f4822516bdd26528aa2e6d8d69c1291c8d3 2020-10-21T09:47:29Z Julian Andres Klode julian.klode@canonical.com 2020-10-21T09:47:29Z urn:sha1:998a17d7e6f834c341f198ca5b6df2f27e18df38 We are seeing more and more installations fail due to immediate configuration issues related to libc6. Immediate configuration is supposed to ensure that an essential package is configured immediately, just in case some other packages use a part of the essential package that only works if that package is configured. This used to be a warning, it was turned into an error in some commit I can't remember right now, but importantly, the error missed a return, which means that ordering completed succesfully and packages were being installed anyway; and after all that happened successfully, we'd print an error at the end and exit with an error code, which is not super useful. Revert the error back to a warning such that the behavior stays the same but we do not fail (unless we mess up ordering which then gets caught by a consistency check later on. Closes: #953260 Closes: #972552 LP: #1871268 2020-02-26T13:12:34Z Julian Andres Klode julian.klode@canonical.com 2020-02-26T13:12:34Z urn:sha1:dc911bdda7cce03bf2b4dd4cfc37bae044ad9f2a 2020-02-26T13:10:47Z Julian Andres Klode julian.klode@canonical.com 2020-02-26T13:09:52Z urn:sha1:069c2e86b21e24e05d3ef8b333d50550a38fa5e2