Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.2.0 2018-09-11T11:08:58Z 2018-09-11T11:08:58Z David Kalnischkies david@kalnischkies.de 2018-09-10T19:34:11Z urn:sha1:329c8d5e149465003ea9007661a7af1099c75c43 We are seeing 'processing' messages from dpkg first, so it makes sense to translate them to "Preparing" messages instead of using "Installing" and co to override these shortly after with the "Preparing" messages. The difference isn't all to visible as later messages tend to linger far longer in the display than the ealier ones, but at least in a listing it seems more logical. 2018-09-11T11:08:58Z David Kalnischkies david@kalnischkies.de 2018-09-10T16:43:34Z urn:sha1:f484906eff85c8c9eadc13ce817d8857abdd08e8 The progress reporting relies on parsing the status reports of dpkg which used to repeat being in the same state multiple times in the same run, but by fixing #365921 it will stop doing so. The problem is in theory just with 'config-files' in case we do purge as this (can) do remove + purge in one step, but we remove this also for the unpack + configure combination althrough we handle these currently in two independent dpkg calls. 2016-06-08T15:31:45Z David Kalnischkies david@kalnischkies.de 2016-06-08T15:31:45Z urn:sha1:b4450f1dd6bca537e60406b2383ab154a3e1485f We end our operation by calling "dpkg --configure -a", so instead of running a (big) configure run with all packages mentioned explicitly before this, we simply skip them and let them be handled by this call implicitly. There isn't really an observeable gain to be had here from a speed point, but it helps in avoiding an (uncommon) problem of having a too long commandline passed to dpkg, which we would split up (probably incorrectly). 2016-05-27T17:14:38Z David Kalnischkies david@kalnischkies.de 2016-05-27T16:10:39Z urn:sha1:b58e2c7c56b1416a343e81f9f80cb1f02c128e25 Setting the C++ locale via std::locale::global(std::locale("")); which would otherwise default to the default C locale (aka: unaffected by setlocale) effects the formatting of numeric types in IO streams, which for output for humans is perfectly sensible, but breaks our many text interfaces used and parsed by us and others without expecting the numbers to be formatted. Closes: #825396 2016-03-16T16:52:40Z Michael Vogt mvo@ubuntu.com 2016-03-15T13:50:37Z urn:sha1:fb193b1cd43f0e8c3b7e5f69f183b9abe7e83761 For the non-pdiff case, we have can have accurate progress reporting because after fetching the {,In}Release files we know how many IndexFiles will be fetched and what size they have. Therefore init the filesize early (in pkgAcqIndex::Init) and ensure that in Acquire::Pulse() looks at already downloaded bits when calculating the progress in Acquire::Pulse. Also improve debug output of Debug::acquire::progress 2015-12-19T22:04:34Z David Kalnischkies david@kalnischkies.de 2015-12-15T16:20:26Z urn:sha1:3abb6a6a1e485b3bc899b64b0a1b7dc2db25a9c2 This doesn't allow all tests to run cleanly, but it at least allows to write tests which could run successfully in such environments. Git-Dch: Ignore 2015-06-15T21:35:55Z David Kalnischkies david@kalnischkies.de 2015-06-15T21:06:56Z urn:sha1:9d2a8a7388cf3b0bbbe92f6b0b30a533e1167f40 It shouldn't be too common, but sometimes people have multiple mirrors in the sources or otherwise repositories with the same content. Now that we gracefully can handle multiple requests to the same URI, we can also fold multiple requests with the same expected hashes into one. Note that this isn't trying to find oppertunities for merging, but just merges if it happens to encounter the oppertunity for it. This is most obvious in the new testcase actually as it needs to delay the action to give the acquire system enough time to figure out that they can be merged. 2015-06-15T21:35:54Z David Kalnischkies david@kalnischkies.de 2015-06-15T11:36:11Z urn:sha1:ff86d7df6a53ff6283de4b9a858c1dad98ed887f All other methods call it, so they should follow along even if the work they do afterwards is hardly breathtaking and usually results in a URIDone pretty soon, but the acquire system tells the individual item about this via a virtual method call, so even through none of our existing items contains any critical code in these, maybe one day they might. Consistency at least once… Which is also why this has a good sideeffect: file: and cdrom: requests appear now in the 'apt-get update' output. Finally - it never made sense to hide them for me. Okay, I guess it made before the new hit behavior, but now that you can actually see the difference in an update it makes sense to see if a file: repository changed or not as well. 2015-03-16T17:01:54Z David Kalnischkies david@kalnischkies.de 2015-03-09T23:59:44Z urn:sha1:25b86db159fbc3c043628e285c0c1ef24dec2c6e We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore 2014-12-07T18:12:51Z David Kalnischkies david@kalnischkies.de 2014-11-18T18:53:56Z urn:sha1:ecb777ddb4d13bb7a18bbf2ebb8e2c810dcaeb72 dpkg checks now for dependencies before running triggers, so that packages can now end up in trigger states (especially those we are not touching at all with our calls) after apt is done running. The solution to this is trivial: Just tell dpkg to configure everything after we have (supposely) configured everything already. In the worst case this means dpkg will have to run a bunch of triggers, usually it will just do nothing though. The code to make this happen was already available, so we just flip a config option here to cause it to be run. This way we can keep pretending that triggers are an implementation detail of dpkg. --triggers-only would supposely work as well, but --configure is more robust in regards to future changes to dpkg and something we will hopefully make use of in future versions anyway (as it was planed at the time this and related options were implemented). Closes: 769609