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-11-22T21:58:33Z Julian Andres Klode jak@debian.org 2016-09-27T22:49:45Z urn:sha1:49521f87851089bdb4097b715d09a8bd348aa60a Our profile says we spend about 5% of the time transforming the hex digits into the binary format used by HashsumValue, all for comparing them against the other strings. That makes no sense at all. According to callgrind, this reduces the overall instruction count from 5,3 billion to 5 billion in my example, which roughly matches the 5%. 2016-11-22T21:58:19Z Julian Andres Klode jak@debian.org 2016-09-27T22:05:31Z urn:sha1:c0723bf1a60daf45096998d4ae9feee3c44343f8 Generating a string for each version we see is somewhat inefficient. The problem here is that the Description tag names are longer than 15 byte, and thus require an allocation on the heap, which we should avoid. It seems reasonable that 20 characters works for all languages codes used for archive descriptions, but if not, there's a warning, so we'll catch that. This should improve performance by about 2%. 2016-11-22T21:58:18Z Julian Andres Klode jak@debian.org 2016-09-27T16:28:55Z urn:sha1:f903069c139df58d1ba855f7cf02c4a2d4e51dc3 Stop copying stuff, and just parse the bytes one by-one to the newly created AddCRC16Byte. This improves the instruction count for an update run from 720,850,121 to 455,801,749 according to callgrind. 2016-11-22T21:58:18Z Julian Andres Klode jak@debian.org 2016-09-27T16:20:02Z urn:sha1:7a3b00b10b6a5a740e07fc1b68a4f3fb3bcdac23 This one has some obvious collisions for non-alphabetical characters, like some control characters also hashing to numbers, but we don't really have those, and these are hash functions which are not collision free to begin with.