apt/test/integration/test-explore-or-groups-in-markinstall, branch 2.1.2

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.

Explore or-groups for Recommends further than first

2020-04-27T11:44:24Z

MarkInstall only looks at the first alternative in an or-group which has a fighting chance of being satisfiable (= the package itself satisfies the dependency, if it is installable itself is not considered). This is "hidden" for Depends by the problem resolver who will try another member of the or-group later, but Recommends are not a problem for it, so for them the alternatives are never further explored. Exploring the or-group in MarkInstall seems like the better choice for both types as that frees the problem resolver to deal with the hard things like package conflicts.