| Age | Commit message (Collapse) | Author |
|---|
|
Our error reporting is historically grown into some kind of mess.
A while ago I implemented stacking for the global error which is used in
this commit now to wrap calls to functions which do not report (all)
errors via return, so that only failures in those calls cause a failure
to propergate down the chain rather than failing if anything
(potentially totally unrelated) has failed at some point in the past.
This way we can avoid stopping the entire acquire process just because a
single source produced an error for example. It also means that after
the acquire process the cache is generated – even if the acquire
process had failures – as we still have the old good data around we can and
should generate a cache for (again).
There are probably more instances of this hiding, but all these looked
like the easiest to work with and fix with reasonable (aka net-positive)
effects.
|
|
We deal with Conflicts in SmartUnpack in pretty much the same way, but
Breaks weren't handled in SmartConfigure so that the remove was sheduled
after the configuration of the package breaking the to-be-removed.
Closes: 796070
|
|
|
|
More standardization
|
|
We aren't and we will not be really compatible again with the previous
stable abi, so lets drop these markers (which never made it into a
released version) for good as they have outlived their intend already.
Git-Dch: Ignore
|
|
Doing this disables the implicit copy assignment operator (among others)
which would cause hovac if used on the classes as it would just copy the
pointer, not the data the d-pointer points to. For most of the classes
we don't need a copy assignment operator anyway and in many classes it
was broken before as many contain a pointer of some sort.
Only for our Cacheset Container interfaces we define an explicit copy
assignment operator which could later be implemented to copy the data
from one d-pointer to the other if we need it.
Git-Dch: Ignore
|
|
The bugreport itself describes the case of the ordering code detecting a
loop where none is present, but the testcase finds also cases in which
there is actually a loop and we fail to realize it. --reinstall can be
considered an interactive command through and it usually doesn't
encounter such "hard" problems (= looping essentials), so this is less
serious than it sounds at first.
Closes: 770291
|
|
Git-Dch: Ignore
|
|
These functions check the exit code of the command, but for apt commands
we can go further and require an error message for non-zero exits and
none for zero exits.
Git-Dch: Ignore
|
|
Reported-By: gcc -Wpedantic
Git-Dch: Ignore
|
|
Conflicts:
apt-pkg/acquire-item.cc
configure.ac
debian/changelog
doc/apt-verbatim.ent
doc/po/apt-doc.pot
doc/po/de.po
doc/po/es.po
doc/po/fr.po
doc/po/it.po
doc/po/ja.po
doc/po/pt.po
po/ar.po
po/ast.po
po/bg.po
po/bs.po
po/ca.po
po/cs.po
po/cy.po
po/da.po
po/de.po
po/dz.po
po/el.po
po/es.po
po/eu.po
po/fi.po
po/fr.po
po/gl.po
po/hu.po
po/it.po
po/ja.po
po/km.po
po/ko.po
po/ku.po
po/lt.po
po/mr.po
po/nb.po
po/ne.po
po/nl.po
po/nn.po
po/pl.po
po/pt.po
po/pt_BR.po
po/ro.po
po/ru.po
po/sk.po
po/sl.po
po/sv.po
po/th.po
po/tl.po
po/tr.po
po/uk.po
po/vi.po
po/zh_CN.po
po/zh_TW.po
test/integration/test-ubuntu-bug-346386-apt-get-update-paywall
|
|
With the change of SmartConfigure() in git commit 42d51f the ordering
code was trying to re-order dependencies, even when at this point in
time this was not needed. Now it will first check all targets of the
given dependency and only if there is not a good one try to reorder
and unpack/configure as needed.
Closes: LP: #1347721
|
|
Conflicts:
test/integration/test-bug-747261-arch-specific-conflicts
|
|
As outlined in #748355 apt segfaulted if it encountered a loop between a
package pre-depending on a package conflicting with the previous as it
ended up in an endless loop trying to unpack 'the other package'.
In this specific case as an essential package is involved a lot of force
needs to be applied, but can also be caused by 'normal' tight loops and
highlights a problem in how we handle breaks which we want to avoid.
The fix comes in multiple entangled changes:
1. All Smart* calls are guarded with loop detection. Some already had it,
some had parts of it, some did it incorrect, and some didn't even try.
2. temporary removes to avoid a loop (which is done if a loop is
detected) prevent the unpack of this looping package (we tried to unpack
it to avoid the conflict/breaks, but due to a loop we couldn't, so we
remove/deconfigure it instead which means we can't unpack it now)
3. handle conflicts and breaks very similar instead of duplicating most
of the code. The only remaining difference is, as it should:
deconfigure is enough for breaks, for conflicts we need the big hammer
|
|
These failure conditions come with an error message attached and the
conditions aren't workaroundable (otherwise this would have been done
instead of returning failure), so not erroring out here means that we
execute dpkg later on with a known not-working ordering adding insult
(our own error messages at the end) to injury (dpkg failure).
|
|
APT_PKG_MINOR < 13)
|
|
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
|
|
Beside being a bit cleaner it hopefully also resolves oddball problems
I have with high levels of parallel jobs.
Git-Dch: Ignore
Reported-By: iwyu (include-what-you-use)
|
|
Git-Dch: Ignore
|
|
|
|
APT_PKG_MINOR >= 13)
|
|
|
|
this
|
|
point, breaks ABI/API, lets see what we can do about this
|
|
* apt-pkg/packagemanager.cc:
- increate APT::pkgPackageManager::MaxLoopCount to 5000
|
|
fixup for 42d51f333e8ef522fed02cdfc48663488d56c3a3
The for-loop iterating over the DepIterators which need configuration
can (and will be in 'complicated' situations) run multiple times, so we
can't just GlobOr on the DepIterator as it modifies it, so that the next
iteration over the list ends up checking another dependency leading us
into a 'Internal error, packages left unconfigured. foopkg' maybe or we
are 'lucky' and calculate a solution which might break down the line
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
|
|
- do not do lock-step configuration for a M-A:same package if it isn't
unpacked yet in SmartConfigure and do not unpack a M-A:same package
again in SmartUnPack if we have already configured it (LP: #1062503)
|
|
and avoid re-unpack otherwise (Closes: #670900)
|
|
- unpack versions in case a different version from the package
is currently in unpack state to recover from broken system states
(like different file in M-A:same package and other dpkg errors)
|
|
- do not segfault if nothing can be configured to statisfy
a pre-depends (e.g. in a pre-depends loop) (Closes: #681958)
|
|
- do not run into loop on new-pre-depends-breaks (Closes: #673536)
|
|
|
|
- iterate over all pre-depends or-group member instead of looping
endlessly over the first member in SmartUnpack (LP: #985852)
|
|
- init counter in SmartConfigure so that the loop-breaker isn't
triggered at random… (Closes: #669060)
|
|
message
|
|
ordering code does not get into a endless loop when it flip-flops
between two states
|
|
|
|
|
|
- recheck all dependencies if we changed a package in SmartConfigure
as this could break an earlier dependency (LP: #940396)
|
|
|
|
|
|
- fix inconsistent clog/cout usage in the debug output
|
|
* apt-pkg/packagemanager.cc:
- fix bug in predepends handling - ensure that packages that needs
unpackaging are unpacked before they are configured (LP: #927993)
[ Julian Andres Klode ]
* apt-pkg/deb/deblistparser.cc:
- Set the Essential flag on APT instead of only Important
* apt-pkg/packagemanager.cc:
- Do not use immediate configuration for packages with the Important flag
* Treat the Important flag like the Essential flag with those differences:
- No Immediate configuration (see above)
- Not automatically installed during dist-upgrade
- No higher score for installation ordering
|
|
- fix bug in predepends handling - ensure that packages that needs
unpackaging are unpacked before they are configured (LP: #927993)
|
|
- No Immediate configuration (see above)
- Not automatically installed during dist-upgrade
|
|
- Do not use immediate configuration for packages with the Important flag
|
|
initialized in the constructor." messages (no functional change)
|
|
- do not try to a void a breaks if the broken package pre-depends
on the breaker, but let dpkg auto-deconfigure it
|
|
|
