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

Propagate protected to already satisfied dependencies

2020-05-18T13:55:36Z

The previous commit deals with negative, now we add the positive side of things as well which makes this a recursive endevour. As we can push the protected flag forward only if a single solution for a dependency exists it is easy for trees to not get it, so if resolving becomes difficult it won't help at all.

Propagate protected to already satisfied conflicts

2020-05-18T13:55:36Z

If we propagate protected e.g. due to a user request we should also act upon (at the moment) satisfied negative dependencies so that the resolver knows that installing this package later is not an option. That the problem resolver is trying bad solutions is a bug by itself which existed before and after and should be worked on. Closes: #960705

Deal with protected solution providers first

2020-05-18T13:55:36Z

For positive dependencies this isn't giving much as the dependency should already be satisfied by such a provider if its protectiveness would help, but it doesn't hurt to check them first and for negative dependencies it means that we check those first which are the most likely to fail to be removed – which is a good idea.

Move the MarkInstall helpers into static functions

2020-05-18T13:55:36Z

Reducing the scope of these helpers might allow us to move them elsewhere and share them or it is a rather pointless exercise, we will see where it leads us to later on. Gbp-Dch: Ignore

Keep going if a dep is bad for user requests to improve errors

2020-05-18T13:55:36Z

We exit early from installing dependencies of a package only if it is not a user request to avoid polluting the state with installs which might not be needed (or detrimental even) for alternative choices. We do continue with installing dependencies though if it is a user request as it will improve error reporting for apt and can even help aptitude not hang itself so much as we trim the problem space down for its resolver dealing with all the easy things. Similar things can be said about the testcase I have short-circuit previously… keep going test, do what you should do to report errors!

Allow aptitude to MarkInstall broken packages via FromUser

2020-05-08T13:52:14Z

apt marks packages coming from the commandline among others as protected to ensure the various resolver parts do not fiddle with the state of these packages. aptitude (and potentially others) do not so the state is modified (to a Keep which for uninstalled means it is not going to be installed) due to being uninstallable before the call fails – basically reverting at least some state changes the call made before it realized it has to fail, which is usually a good idea, except if users expect you to not do it. They do set the FromUser option though which has beside controlling autobit also gained the notion of "the user is always right" over time and can be used for this one here as well preventing the state revert. References: 0de399391372450d0162b5a09bfca554b2d27c3d Reported-By: Jessica Clarke on IRC

Protect a package while resolving in MarkInstall

2020-04-27T11:51:46Z

Strange things happen if while resolving the dependencies of a package said dependencies want to remove the package. The allow-scores test e.g. removed the preferred alternative in favor of the last one now that they were exclusive. In our or-group for Recommends we would "just" not statisfy the Recommends and for Depends we engage the ProblemResolver…

Prefer upgrading installed orgroup members

2020-04-27T11:49:43Z

In normal upgrade scenarios this is no problem as the orgroup member will be marked for upgrade already, but on a not fully upgraded system (or while you operate on a different target release) we would go with our usual "first come first serve" approach which might lead us to install another provider who comes earlier – bad if the providers conflict.

Propagate Protected flag to single-option dependencies

2020-04-27T11:49:19Z

If a package is protected and has a dependency satisfied only by a single package (or conflicts with a package) this package must be part of the solution and so we can help later actions not exploring dead ends by propagating the protected flag to these "pseudo-protected" packages. An (obscure) bug this can help prevent (to some extend) is shown in test-apt-never-markauto-sections by not causing irreversible autobit transfers. As a sideeffect it seems also to help our crude ShowBroken to display slightly more helpful messages involving the packages which are actually in conflict.

Fail earlier on impossible Conflicts in MarkInstall

2020-04-27T11:48:33Z

MarkDelete is not recursive as MarkInstall is and we can not conflict with ourselves anyhow, so we can move the unavoidable deletes before changing the state of the package in question avoiding the need for the state update in case of conflicts we can not deal with (e.g. the package conflicts with an explicit user request).