Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4_beta2 2016-11-23T23:21:35Z 2016-11-23T23:21:35Z David Kalnischkies david@kalnischkies.de 2016-11-23T22:09:05Z urn:sha1:8e7a99564dd57b0dcb7df47b43e71ccefc8e0ebe 2016-11-23T23:21:35Z David Kalnischkies david@kalnischkies.de 2016-11-23T21:17:01Z urn:sha1:bb9c5972524ac5c078fa0f0bc5674c7a0fe01fb4 We try to configure all packages at the end which need to be configured, but that also applies to packages which weren't completely installed (e.g. maintainerscript failed) we end up removing in this interaction instead. APT doesn't perform this explicit configure in the end as it is using "dpkg --configure --pending", but it does confuse the progress report and potentially also hook scripts. Regression-Of: 9ffbac99e52c91182ed8ff8678a994626b194e69 2016-11-23T23:21:35Z David Kalnischkies david@kalnischkies.de 2016-11-23T18:02:51Z urn:sha1:53f3fc59f4eb37eea57bbde53fb75f2e15af0378 dpkg stumbles over these (#844300) and we haven't dropped 'easier' removes to be implicit and to be scheduled by dpkg by default so far so we shouldn't push the decision in such cases to dpkg either. 2016-11-23T23:21:35Z David Kalnischkies david@kalnischkies.de 2016-11-23T16:32:20Z urn:sha1:4b10240cca0dc0a4e82e42959545d2ae7e622d29 Our old idea was to look for the first package which would be "touched" and take this as the package dpkg is talking about, but that is incorrect in complicated situations like a package upgraded to/from multiple M-A:same siblings installed. As we us the progress report to decide what is still needed we have to be reasonabily right about the package dpkg is talking about, so we jump to quite a few loops to get it. 2016-11-23T15:37:39Z David Kalnischkies david@kalnischkies.de 2016-11-12T10:32:13Z urn:sha1:dabe9e2482180ada77d2adda2b3c03db22059fb8 Given that we use the progress information to skip over actions dpkg has already done like not purging a package which was already removed and had no config files or not acting on disappeared packages and such it is important that apt and dpkg agree on which states the package has to pass through. To ensure that we keep tabs on this in the future a warning is added at the end if apt hasn't seen all the action it was supposed to see. I can't wait for the first bugreporters to wonder about this… 2016-11-23T15:37:39Z David Kalnischkies david@kalnischkies.de 2016-11-18T11:04:08Z urn:sha1:066d4a5bab628ef8220971bb5763ff8f3a13de07 If a package is triggered dpkg frequently issues two messages about it causing us to make a note about it both times which messes up our planned dpkg actions view. Adding these actions if we have nothing else planned fixes this and should still be correct as those planned actions will deal with the triggering just fine and we avoid strange problems like a package triggered before its removed… 2016-08-26T22:31:03Z Julian Andres Klode jak@debian.org 2016-08-26T22:31:03Z urn:sha1:6a68315e938eb2611806658828ecea86805822e7 2016-08-26T13:49:10Z Julian Andres Klode jak@debian.org 2016-08-23T11:15:15Z urn:sha1:24a59c62efafbdb8387b2d3c5616b04b9fd21306 Several modules use std::array without including the array header. Bad modules. Some modules use STDOUT_FILENO and friends, or close() without including unistd.h, where they are defined. One module also uses WIFEXITED() without including sys/wait.h. Finally, environ is not specified to be defined in unistd.h. We are required to define it ourselves according to POSIX, so let's do that. 2016-08-25T14:12:24Z David Kalnischkies david@kalnischkies.de 2016-08-25T13:52:30Z urn:sha1:4f242a2289cc5db7a53afdb875291c94de64fd90 Ubuntu uses *.ddeb files for their debug packages, but the interface we are using since f495992428a396e0f98886c9a761a804aa161c68 to talk to dpkg isn't supporting *.ddeb files. This used to work previously as apt itself isn't caring about the filenames at all and if they are explicitly mentioned dpkg will accept all, too. It might or might not be a good idea to patch dpkg, too, but regardless of it happening, we don't want to couple us to closely to dpkg for this minor feature but testing for this at runtime as it would delay shipping the fix for the too long commandlines further. It is also questionable if it is really a good idea to allow any file extension to be used here (like .foobar in the testcase), but we used to and we tend to avoid breaking existing usecases if we can help it. As a bonus, this also allows the installation of ddeb files directly from the commandline as you can with deb files already. We continue to ignore udeb through as the user-mistake to useful ratio is too high. LP: #1616909 2016-08-24T20:37:41Z David Kalnischkies david@kalnischkies.de 2016-08-24T19:57:53Z urn:sha1:70ff288b98a7aae2c2808112015d34f76f2d5114 In most cases apt was already skipping the (re)setting of packages as to be removed/purged if dpkg had told us that it already did, but we haven't dealt with it in the most obvious of the cases: Selections set for packages we touched in this operation which either restores selections even dpkg would have overridden or e.g. tries to restore a purge selection for a package which was just purged – does not happen with apt itself as it isn't using selections in this way, but higher frontends like aptitude do. The result in the later case is a warning printed by dpkg that we try to set selections for an unknown package, which is harmless per se, but can be confusing for users and we really shouldn't cause warnings in dpkg if we can help it. Reported-By: Guillem Jover on IRC