| Age | Commit message (Collapse) | Author |
|---|
|
Previously, we had a start and a done of the calculation printed by
higher-level code, but this got intermixed by progress reporting from an
external solver or the output of autoremove code…
The higherlevel code is now only responsible for instantiating a
progress object of its choosing (if it wants progress after all) and the
rest will be handled by the upgrade code. Either it is used to show the
progress of the external solver or the internal solver will give some
hints about its overall progress. The later isn't really a proper
progress as it will jump forward after each substep, but that is at
least a bit better than before without any progress indication.
Fixes also the 'strange' non-display of this progress line in -q=1, while
all others are shown, which is reflected by all testcase changes.
|
|
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
|
|
Git-Dch: Ignore
|
|
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
|
