apt/apt-pkg, branch 2.3.4

Merge branch 'master' of https://github.com/kraj/apt

2021-05-05T10:14:11Z

See https://github.com/Debian/apt/pull/129

Merge branch 'pu/upgradecounter' into 'main'

2021-04-29T08:28:08Z

Count uninstallable packages in "not upgraded" See merge request apt-team/apt!169

Merge branch 'pu/autoremove' into 'main'

2021-04-29T08:26:11Z

Mark only provides from protected versioned kernel packages See merge request apt-team/apt!168

Store versioned kernel package detectors in d-pointer

2021-04-26T11:00:24Z

They are kinda costly, so it makes more sense to keep them around in private storage rather than generate them all the time in the MarkPackage method. We do keep them lazy through as we have that implemented already.

Call MarkAndSweep only manually in apt-get for autoremove

2021-04-26T11:00:24Z

An interactive tool like aptitude needs these flags current far more often than we do as a user can see them in apt only in one very well defined place – the autoremove display block – so we don't need to run it up to four times while a normal "apt install" is processed as that is just busywork. The effect on runtime is minimal, as a single run doesn't take too long anyhow, but it cuts down tremendously on debug output at the expense of requiring some manual handholding. This is opt-in so that aptitude doesn't need to change nor do we need to change our own tools like "apt list" where it is working correctly as intended. A special flag and co is needed as we want to prevent the ActionGroup inside pkgDepCache::Init to be inhibited already so we need to insert ourselves while the DepCache is still in the process of being built. This is also the reason why the debug output in some tests changed to all unmarked, but that is fine as the marking could have been already obsoleted by the actions taken, just inhibited by a proper action group.

Reexplore providers of marked packages if some didn't satisfy before

2021-04-26T11:00:24Z

The autoremove algorithm would mark a package previously after exploring it once, but it could have been that it ignored some providers due to them not satisfying the (versioned) dependency. A later dependency which they might satisfy would encounter the package as already marked and hence doesn't explore the providers anymore leaving us with internal errors (as in the contrived new testcase). This is resolved by introducing a new flag denoting if we explored every provider already and only skip exploring if that is true, which sounds bad but is really not such a common occurrence that it seems noticeable in practice. It also helps us marking virtual packages as explored now which would previously be tried each time they are encountered mostly hiding this problem for the (far more common) fully virtual package.

Count uninstallable packages in "not upgraded"

2021-04-25T14:25:57Z

If a first step of the solver can figure out that a package is uninstallable it might reset the candidate so that later steps are prevented from exploring this dead end. While that helps the resolver it can confuse the display of the found solution as this will include an incorrect count of packages not upgraded in this solution. It was possible before, but happens a fair bit more with the April/May resolver changes last year so finally doing proper counting is a good idea. Sadly this is a bit harder than just getting the number first and than subtracting the packages we upgraded from it as the user can influence candidates via the command line and a package which could be upgraded, but is removed instead shouldn't count as not upgraded as we clearly did something with it. So we keep a list of packages instead of a number which also help in the upgrade cmds as those want to show the list. Closes: #981535

Mark only provides from protected versioned kernel packages

2021-04-25T12:23:13Z

An out-of-tree kernel module which doesn't see many new versions can pile up a considerable amount of packages if it is depended on via another packages (e.g.: v4l2loopback-utils recommends v4l2loopback-modules) which in turn can prevent the old kernels from being removed if they happen to have a dependency on the images. To prevent this we check if a provider is a versioned kernel package (like an out-of-tree module) and if so check if that module package is part of the protected kernel set – if not it is probably good to go. We only do this if at least one provider is from a protected kernel though so that the dependency remains satisfied (this can happen e.g. if the module is currently not buildable against a protected kernel).

Allow superfluous commas in build-dependency lines

2021-04-25T10:02:19Z

This code can interact with handwritten files who can have unneeded commas for writing easy. As dpkg allows it, we should do as well. Reported-By: Arnaud Ferraris References: https://lists.debian.org/debian-devel/2021/03/msg00101.html

Streamline or-group closing after other arch-specific package

2021-04-25T09:45:20Z

The comment and code are a bit too roundabout about what they actually try to do, so lets just set that straight as this is really just about a very specific case and doesn't deserve a general resetting. Gbp-Dch: Ignore