1 |
Michael Lienhardt <michael.lienhardt@×××××××.net> wrote: |
2 |
> the criteria list you gave (maybe it's in the PMS) |
3 |
|
4 |
I doubt that it is in PMS, and IMHO it also does not belong there: |
5 |
As long as the result configuration is valid (no collisions |
6 |
or unresolvable loops) all should be equally fine from the |
7 |
viewpoint of PMS: It is in the responsibility of the package |
8 |
manager and its configuration to determine correctly what the |
9 |
_user_ actually wants. |
10 |
|
11 |
> - in criteria a., there could be an ambiguity between what I call a package |
12 |
> (e.g., 'app-editors/nano-2.9.3') and a package group (e.g., |
13 |
> 'app-editors/nano') |
14 |
|
15 |
This is what already Michał has oberved: In my list, I had completely |
16 |
forgotten to refer to versions ('app-editors/nano-2.9.3') and had only |
17 |
packages ('app-editors/nano') in mind. |
18 |
(I think "version" vs. "package" is the usual terminology in gentoo; |
19 |
there are also "slots" which in a sense might be considered as |
20 |
different packages, although perhaps with a different "penalty") |
21 |
|
22 |
> is the criteria about package group (i.e., are version changes allowed)? |
23 |
|
24 |
Version upgrades should even be preferred over remaining with the version. |
25 |
OTOH, version downgrades are perhaps even worse than using a different package |
26 |
(opinions might differ for the latter). |
27 |
|
28 |
> - similarly in criteria b.: is this criteria valid across versions |
29 |
> (i.e., when changing version, the USE-flag change should be minimal) |
30 |
|
31 |
Cf. the next point: The USE-flag change compared to user configuration |
32 |
(package.use etc.) should be minimal. |
33 |
|
34 |
> - just to be sure, the "less keyword and mask change" criteria is at the |
35 |
> top of the list? |
36 |
|
37 |
Yes. Only "illegal" configurations (colliding packages or unresolvable |
38 |
dependency loops of uninstalled packages) should weight stronger: |
39 |
If possible at all, the user's choice should always be preferred, |
40 |
and changes to the configuration should only be suggested if no other |
41 |
solution exists (and probably the number of suggested changes should |
42 |
be minimal in a sense). |