Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4.2 2017-01-19T14:59:38Z 2017-01-19T14:59:38Z David Kalnischkies david@kalnischkies.de 2017-01-19T14:14:19Z urn:sha1:93cff633a830e222693fc0f3d78e6e534d1126ee Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian 2017-01-19T14:59:38Z David Kalnischkies david@kalnischkies.de 2017-01-19T12:41:25Z urn:sha1:99b1cdd3a07576542c8bda40d93368f3f76db912 Nothing in user visible strings. Gbp-Dch: Ignore Reported-By: codespell 2016-12-31T17:23:25Z David Kalnischkies david@kalnischkies.de 2016-12-31T17:23:25Z urn:sha1:4e18c2cee6da39982cc463cafbf27eab5561099f Interpreting a boolean as an int works just fine – it just hasn't the intended result – it isn't a serious problem through as the disabling of the usage of this dpkg calling style is just an "optimization" 2016-12-31T01:29:21Z David Kalnischkies david@kalnischkies.de 2016-12-30T23:04:50Z urn:sha1:c8f0f5bd1effdf80c2eee80b3aa4eeb35604a2a1 Unlikely to have any practical effect, but its more consistent to use the right methods instead of performing it slightly incorrect by hand. Gbp-Dch: Ignore 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…