1 |
Le 17/06/2020 à 08:15, Michał Górny a écrit : |
2 |
> On Tue, 2020-06-16 at 23:07 +0000, Michael Lienhardt wrote: |
3 |
>> Dear all, |
4 |
>> |
5 |
>> My bad for not noticing it sooner, but when there is a dependency like ">=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in virtual/libgudev-215-r3), |
6 |
>> since 'static-libs' is not a use flags of sys-fs/udev-242, that cpv is silently not considered during dependency solving by emerge. |
7 |
>> However, the PMS states: |
8 |
>> - it is an error for a use dependency to be applied to an ebuild which does not have the flag in question in IUSE_REFERENCEABLE |
9 |
>> |
10 |
> |
11 |
> This is a bit like undefined behavior. PMS says such a thing shouldn't |
12 |
> happen (i.e. the ebuild is wrong) but does not force specific error |
13 |
> handling. You could reject the ebuild entirely or reject dependencies |
14 |
> that don't have the flag in question (even if it's disabled). You could |
15 |
> also pretend it's 'static-libs(-)?' but that would be bad if the default |
16 |
> was supposed to be '(+)'. |
17 |
|
18 |
Indeed. It's true that when I read "error" I understand "something that |
19 |
never occur in a distributed gentoo repository". |
20 |
|
21 |
> |
22 |
>> This is related to the tool I'm working on: should my tool allow this behavior, or fail like it is currently doing (I guess the former)? |
23 |
> |
24 |
> That depends on what the tool is doing. I suppose you probably don't |
25 |
> need very strict behavior there. |
26 |
|
27 |
Indeed, I don't need a strict behavior, but since I saw an ambiguity |
28 |
between the PMS and emerge, I went to check with you if this ambiguity |
29 |
was intentional, and found out along the way how to deal with this |
30 |
situation in my tool. My tool is still the SAT-based dependency analysis |
31 |
you don't really believe in :p. It's going forward slowly but (among |
32 |
other things) thanks to the help of you all, I got a paper accepted to a |
33 |
top software engineering conference. So, thanks! Of course, my final |
34 |
goal is to have the tool fully functional (it will the subject of two |
35 |
other papers -- there's a lot to say on how to deal with gentoo). |
36 |
|
37 |
Since the current gentoo repo includes "erroneous" 2-style USE |
38 |
dependency, I will change my tool's current behavior (raising an error) |
39 |
to the "no match with warning" that Zac proposed (which seems the safest |
40 |
approach to take in the current situation). |
41 |
|
42 |
Best, |
43 |
Michael |