Gentoo Archives: gentoo-dev

From: Martin Vaeth <martin@×××××.de>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: SAT-based dependency solver: request for test cases
Date: Tue, 13 Feb 2018 12:39:07
Message-Id: p5um3c$vi3$
In Reply to: Re: [gentoo-dev] Re: SAT-based dependency solver: request for test cases by Michael Lienhardt
Michael Lienhardt <michael.lienhardt@×××××××.net> wrote:
> the criteria list you gave (maybe it's in the PMS)
I doubt that it is in PMS, and IMHO it also does not belong there: As long as the result configuration is valid (no collisions or unresolvable loops) all should be equally fine from the viewpoint of PMS: It is in the responsibility of the package manager and its configuration to determine correctly what the _user_ actually wants.
> - in criteria a., there could be an ambiguity between what I call a package > (e.g., 'app-editors/nano-2.9.3') and a package group (e.g., > 'app-editors/nano')
This is what already Michał has oberved: In my list, I had completely forgotten to refer to versions ('app-editors/nano-2.9.3') and had only packages ('app-editors/nano') in mind. (I think "version" vs. "package" is the usual terminology in gentoo; there are also "slots" which in a sense might be considered as different packages, although perhaps with a different "penalty")
> is the criteria about package group (i.e., are version changes allowed)?
Version upgrades should even be preferred over remaining with the version. OTOH, version downgrades are perhaps even worse than using a different package (opinions might differ for the latter).
> - similarly in criteria b.: is this criteria valid across versions > (i.e., when changing version, the USE-flag change should be minimal)
Cf. the next point: The USE-flag change compared to user configuration (package.use etc.) should be minimal.
> - just to be sure, the "less keyword and mask change" criteria is at the > top of the list?
Yes. Only "illegal" configurations (colliding packages or unresolvable dependency loops of uninstalled packages) should weight stronger: If possible at all, the user's choice should always be preferred, and changes to the configuration should only be suggested if no other solution exists (and probably the number of suggested changes should be minimal in a sense).