Gentoo Archives: gentoo-portage-dev

From: Michael Lienhardt <michael.lienhardt@×××××××.net>
To: "Michał Górny" <mgorny@g.o>
Cc: gentoo-portage-dev@l.g.o, Brian Dolbec <dolsen@g.o>
Subject: Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?
Date: Wed, 17 Jun 2020 12:26:49
Message-Id: bd90f0ee-3e2c-75f6-92de-076022cc2203@laposte.net
In Reply to: Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies? by "Michał Górny"
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