| Age | Commit message (Collapse) | Author |
|---|
|
With b4450f1dd6bca537e60406b2383ab154a3e1485f we dropped what we
calculated here later on and now that we don't need it in the meantime
either we can just skip the busy work by default and expect dpkg to do
the right thing dropping also our little "last explicit configures"
removal trick introduced in b4450f1dd6bca537e60406b2383ab154a3e1485f.
This enables the last of a bunch of previously experimental options,
some of them existing still, but are very special and hence not really
worth documenting anymore (especially as it would need to be rewritten
now entirely) which is why the documentation is nearly completely
dropped.
The order of configuration stanzas in the simulation code changes
slightly as it isn't concerning itself with finding the 'right' order,
but any order is valid anyhow as long as the entire set happens in the
same call.
|
|
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
|
|
apt can work with both, so it has an or-dependency on them,
but the tests want to play with both of them.
Git-Dch: Ignore
|
|
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
|
