Trying harder to find an installable combination when confronted with weird maskings

[robryk]

Suppose we have two packeges, A and B in following versions and follwing dependencies:

A-1 depends on >=B-1 A-2 depends on >=B-2 B-1 and B-2 depend on nothing

B-1, A-1 and A-2 are considered not masked, but B-2 is.

As far as I could tell (I believe this is the situation with eselect and eselect-news if I accept keyword ~x86 for eselect-news, but not eselect) `paludis --dl-upgrade as-needed --install A' would then try to install A-2, find B-2 masked and fail.

I understand that such a situation is considered a bug in repository, but it can arise due to setting accepted keywords individually/ unmasking individual packages. For example, I want to use eselect-news, so I accepted ~x86 for it, but I still want to have eselect with x86 keyword.

I think that this problem may be solved by making the dependency resolver, having found that installing the newest version of a package is impossible, try to install subsequent older versions, until it reaches one that violates the input atom (ie. is too old).

I would propose to add a per-package option that would change this behaviour, so that one might set it when one unmasks a package or adds an accepted keyword for it.

I am aware that the algorithm I've given will be as straightforward to implement only if the dependency resolver is DFS-esque, but I think that it may be adapted to BFS-esque resolvers also.

Please excuse my possible mistaking the component to which this request pertains.

[ciaranm]

I've got a new resolver locally that does things a bit differently -- it builds up the set of necessary packages first, before doing ordering, so it should handle this kind of thing more elegantly.

[dleverton]

This should be done carefully if at all... you don't want paludis to silently refuse to upgrade a core system package just because the new version has a dependency¹ on a package that you've masked. A warning might be sufficient.

[1] Possibly conditional, but enabled by a globally-enabled flag; otherwise, you'd just have to live with the new dep.

[ciaranm]

The new resolver handles this kind of thing sanely. It won't ever be supported with the legacy resolver.