1 |
Le 17/06/2020 à 10:35, Ulrich Mueller a écrit : |
2 |
>>>>>> On Wed, 17 Jun 2020, Michael Lienhardt wrote: |
3 |
> |
4 |
>> But maybe, "error" here in the PMS mean "the cpvs without the use flag |
5 |
>> does not match that dependency and a warning should be raised to |
6 |
>> improve compatibility in the future". In that case, it would be |
7 |
>> clearer for me to change 'error' in the PMS into something like |
8 |
>> "results in a no match, |
9 |
> |
10 |
> IMHO we cannot assume that. If the flag is not in the dependency's |
11 |
> IUSE_EFFECTIVE then behaviour is undefined. |
12 |
|
13 |
Fair enough. |
14 |
However, currently the PMS says it is an error, not an undefined behavior. |
15 |
|
16 |
>> but should be avoided". That way, it is explicitly stated that missing |
17 |
>> use flags for a 2-style USE dependency is accepted (which is the |
18 |
>> current behavior of emerge) but frown upon, without forcing any |
19 |
>> specific error handling, like Michał accurately pointed out. |
20 |
> |
21 |
> The real problem is that we don't have a good procedure for removing |
22 |
> flags from ebuilds with reverse (2-style) use dependencies. (And even |
23 |
> with 4-style use dependencies the problem remains that one cannot know |
24 |
> in advance whether removal of the flag implies that the feature is now |
25 |
> unconditionally enabled, or that it is disabled.) |
26 |
|
27 |
Indeed. |
28 |
This is outside the scope of my original question, but intuitively, I |
29 |
would imagine that the devs should know why they remove a use flag. It's |
30 |
just an idea, but I see two possibilities. |
31 |
1. either the change is temporary: in that case, they could keep the use |
32 |
flag and set its value in REQUIRED_USE during that period |
33 |
2. either the change is durable: in that case, it is still possible to |
34 |
keep the use flag (while still setting its value in REQUIRED_USE) during |
35 |
a period of time during which it is possible to update the dependencies |
36 |
toward that package (the use flag would become deprecated before being |
37 |
removed). |
38 |
That way, enforcing the error described in the PMS would be telling to |
39 |
the devs that they didn't update their dependencies during the |
40 |
transition period. |
41 |
|
42 |
Best, |
43 |
Michael |