Le 17/06/2020 à 08:15, Michał Górny a écrit :
On Tue, 2020-06-16 at 23:07 +0000, Michael Lienhardt wrote:
Dear all,

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 
  since 'static-libs' is not a use flags of sys-fs/udev-242, that cpv is 
silently not considered during dependency solving by emerge.
However, the PMS states:
  - 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

This is a bit like undefined behavior.  PMS says such a thing shouldn't
happen (i.e. the ebuild is wrong) but does not force specific error
handling.  You could reject the ebuild entirely or reject dependencies
that don't have the flag in question (even if it's disabled).  You could
also pretend it's 'static-libs(-)?' but that would be bad if the default
was supposed to be '(+)'.

Indeed. It's true that when I read "error" I understand "something that never occur in a distributed gentoo repository".

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)?

That depends on what the tool is doing.  I suppose you probably don't
need very strict behavior there.

Indeed, I don't need a strict behavior, but since I saw an ambiguity between the PMS and emerge, I went to check with you if this ambiguity was intentional, and found out along the way how to deal with this situation in my tool. My tool is still the SAT-based dependency analysis you don't really believe in :p. It's going forward slowly but (among other things) thanks to the help of you all, I got a paper accepted to a top software engineering conference. So, thanks! Of course, my final goal is to have the tool fully functional (it will the subject of two other papers -- there's a lot to say on how to deal with gentoo).

Since the current gentoo repo includes "erroneous" 2-style USE dependency, I will change my tool's current behavior (raising an error) to the "no match with warning" that Zac proposed (which seems the safest approach to take in the current situation).


Reply via email to