apt/apt-pkg/depcache.cc, branch 2.1.11

Merge branch 'master' into 'master'

2020-08-04T10:16:36Z

Support marking all newly installed packages as automatically installed See merge request apt-team/apt!110

Filter out impossible solutions for protected propagation

2020-07-02T16:57:11Z

If the package providing the given solution is tagged already for removal (or at least for "not installing") we can ignore this solution as a possibility as it is not one, which means we can avoid exploring the option and potentially forward the protected flag further if that helps in reducing the possibilities to a single one.

Delay removals due to Conflicts until Depends are resolved

2020-07-02T16:57:11Z

Marking a package for removal is fine if we know that we have to remove that package, but if we are in an alternative branch we might not go this route in the end and hence have a package pointlessly marked for removal which isn't questioned later on. We check if we are allowed to remove that package to avoid working on the positive dependencies if not, but we mark them for removal only after all the other dependencies are successfully resolved. In an ideal world we would let the problemResolver do its job on them, but the resolver might decide against doing the removal exploring another option like the next alternative, which might be a good idea, but is not the behaviour we had before, so that is the best we can do for now without changing the resolver drastically.

Support marking all newly installed packages as automatically installed

2020-06-08T10:18:33Z

Add option '--mark-auto' to 'apt install' that marks all newly installed packages as automatically installed. Signed-off-by: Nicolas Schier

Deal with duplicates in the solution space of a dep

2020-06-03T11:41:14Z

While we process the possible solutions we might modify other solutions like discarding their candidates and such, so that then we reach them they might no longer be proper candidates. We also try to drop duplicates early on to avoid the simple cases of these which test-explore-or-groups-in-markinstall triggers via its explicit duplication but could also come via multiple provides. It only worked previously as were ignoring current versions which usually is okay expect if they are marked for removal and we want to reinstate them so the ProblemResolver can decide which one later on.

Don't update candidate provides map if the same as current

2020-05-25T10:05:00Z

Don't set variables to conditionally override them 2 lines later

2020-05-25T10:05:00Z

Gbp-Dch: Ignore

Allow pkgDepCache to be asked to check internal consistency

2020-05-24T19:02:35Z

For speed reasons pkgDepCache initializes its state once and then has a battery of update calls you have to invoke in the right order to update the various states – all in the name of speed. In debug and/or simulation mode we can sacrifice this speed for a bit of extra checking though to verify that we haven't made some critical mistake like #961266.

Keep status number if candidate is discarded for kept back display

2020-05-23T15:59:19Z

It looks like hack and therefore I wanted this to be a very isolated commit so we can find it & revert it easily if need be, but for now it seems to work. The idea is that Status is telling us how the candidate is in relation to the current installed version which is used to figure out if a package is "kept back" by the algorithm or not, but by discarding the candidate version we loose this information. Ideally we would keep better tabs on what we do to a package and why, but for now that seems okayish. It will cause the wrong version to be displayed though as if the package is installed the installed version becomes the candidate and hence (installed => installed) is displayed.

Known-bad candidate versions are not an upgrade option

2020-05-23T15:58:42Z

If we have a negative dependency to deal with we prefer to install an upgrade rather than remove the current version. That is why we split the method rather explicitly in two in 57df273 but there is a case we didn't react to: If we have seen the candidate before as a "satisfier" of this negative dependency there is no point in trying to upgrade to it later on. We keep that info by candidate discard if we can, but even if we can't we can at least keep that info around locally. This "fixes" (or would hide) the problem described in 04a020d as well as you don't have to discard installations you never make.