Age | Commit message (Collapse) | Author | |
---|---|---|---|
2014-04-04 | do not configure already unpacked packages needlessly | David Kalnischkies | |
The unpack of a M-A:same package will force the unpack of all its siblings directly to prevent that they could be separated by later immediate actions. In commit 634985f8 a call to SmartConfigure was introduced to configure these packages at the time the installation order encounters them. Usually, the unpack order is already okay, so that this 'earlier' unpack was not needed and if it wouldn't have been done, the package would now only be unpacked, but by configuring the package now we impose new requirements which must be satisfied. The code is clever enough to handle this most of the time (it worked for 2 years!), but it isn't needed and in very coupled cases this can fail. Removing this call again removes this extra burden and so simplifies the ordering as can be seen in the modified tests. Famous last words, but I don't see a reason for this extra burden to exist hence the remove. Closes: 740843 | |||
2014-02-10 | fix remaining testcase-bugs from my armel box | David Kalnischkies | |
Git-Dch: Ignore | |||
2013-06-09 | do unpacks before configures in SmartConfigure | David Kalnischkies | |
Splits the big loop over dependencies in SmartConfigure which unpacks and configures dependencies into two loops and reverse their order, so that all dependencies which need to be unpacked are handled first and only after that configures are issued for dependencies. This is needed as otherwise the unpack of a (new) dependency will be issued in between a configure call for two (or more) packages which form a loop, which means the configure calls aren't part of the same dpkg call and therefore dpkg bails out. Such tight loops should really be avoided as they are usually wrong – and in reality the dependencies in libreoffice were greatly simplified thanks to Rene Engelhard so the problem is gone for the benefit of all. Closes: 707578 |