apt/test/integration/test-explore-or-groups-in-markinstall, branch 2.1.0Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.1.02020-04-27T11:51:46ZProtect a package while resolving in MarkInstall2020-04-27T11:51:46ZDavid Kalnischkiesdavid@kalnischkies.de2020-04-27T11:51:46Zurn:sha1:ae23e53f99ea0b7920744a7303fdee64796b7cce
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 members2020-04-27T11:49:43ZDavid Kalnischkiesdavid@kalnischkies.de2020-04-26T19:09:14Zurn:sha1:ca14e1e2c3f3c9782f374757ca4605ce7e5670ad
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 dependencies2020-04-27T11:49:19ZDavid Kalnischkiesdavid@kalnischkies.de2020-04-27T11:49:19Zurn:sha1:f76a8d331a81bc7b102bdd4e0f8363e8a59f64f6
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 first2020-04-27T11:44:24ZDavid Kalnischkiesdavid@kalnischkies.de2020-04-25T09:28:47Zurn:sha1:ff4555c72df967e40590d9e8c6ce83e9df4c46ea
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.