Last commit made on 2021-09-07
Get this branch:
git clone -b main https://git.launchpad.net/apt

Branch merges

Branch information


Recent commits

883a123... by Julian Andres Klode

Release 2.3.9

e664bdc... by Julian Andres Klode

Improve error handling of cycling delayed queues

When an item has been delayed and the queue is cycled to start
it, we did not properly report an error from the cycling, and
we would then fail in the assert(), causing all errors to be

Propagate the error instead and make the assert a warning.

25162dd... by Julian Andres Klode

Merge branch 'fix/recursivemark' into 'main'

Fix infinite recursions in MarkPackage and improve recursions in general

See merge request apt-team/apt!183

5f6bbfa... by David Kalnischkies

Increase recursion limits from 100 to 3000

If you install dpkg on an empty status file with all recommends and
suggests apt wants to install 4000+ packages. The deepest chain
seemingly being 236 steps long. And dpkg isn't even the worst (~259).

That is a problem as libapt has a hardcoded recursion limit for
MarkInstall and friends … set to 100. We are saved by the fact that
chains without suggests are much shorter (dpkg has 5, max seems ~43),
but I ignored Conflicts in these chains, which typically trigger
upgrades, so if two of the worst are chained together we suddenly get
dangerously close to the limit still.

So, lets just increase the limit into oblivion as it is really just a
safety measure we should not be running into to begin with. MarkPackage
was running years without it after all. 3000 is picked as a nice number
as any other and because it is roughly the half of the stack crashs I
saw previously in this branch.

c7e368a... by David Kalnischkies

Stop autoremover from endlessly exploring cyclic providers

fullyExplored is needed to keep track of having explored all providers
of a package name, while Marked is tracking if we have explored a given
real package (along its chosen version), so we should stop MarkPackage
from exploring a (real) package if it is marked and let fullyExplored
only guard the looping over the individual dependencies.

The testcase is deceptively simple, but in practice only an ecosystem
like rust who makes heavy use of cyclic dependency relations intermixed
with versioned provides actually triggers this as seen by the buggy code
being in use for four months in Debian and Ubuntu development releases.
(easier to trigger if most packages are marked manual installed)

Note that the testcase is successful already due to the earlier changes
as we exit the recursion eventually and all packages are marked as they
need to be already, but this fix does work standalone as well.

Closes: #992993

e470121... by David Kalnischkies

Don't venture too deeply in AutoRemovers MarkPackage

MarkInstall has the same depth limit, so lets use this arbitrary limit
to avoid trying to hard as that usually means we will never stop – at
least not until we crash, which is not a very good error case.

d7e9f07... by David Kalnischkies

Move hidden MarkPackage to a static function

We can't have external users as its marked hidden and as we don't even
have users outside of pkgDepCache itself we can remove the function
completely from the public eye. That adds many new parameters, but it
also allows to add a few more like avoiding constantly checking the
debug config value.

Gbp-Dch: Ignore

b104891... by David Kalnischkies

Simplify selection of highest source version providers

The old code is a bit longer and does a sort (N*log(N)) + find (at most N)
It is replaced by max_element (N) + remove_if (N). The practical
difference is minimal as the N we operate on is rather small, but the
replacement is hopefully easier to understand at a glance as well.

Gbp-Dch: Ignore

e267d1e... by David Kalnischkies

Inhibit autoremove calculation in apt-mark and apt show

As we never display the information in these code paths there isn't a
lot of point in calculating it first saving us some precious CPU cycles.

References: d6f3458badf2cfea3ca7de7632ae31daff5742be

255ec5a... by David Kalnischkies

Try to show core dump info in test framework

If the system tells us that a core dump was created we should try to
display the contained info as that system might not be easily available
when we see the error (like C-I or autopkgtest).

Gbp-Dch: Ignore