[gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[michael.lienhardt]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

<div style="font-family:Arial, Helvetica, sans-serif; font-size:12px;">‌Dear all,<br>
<br>
My bad for not noticing it sooner, but when there is a dependency like "&gt;=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in virtual/libgudev-215-r3), since 'static-libs' is not a use flags of sys-fs/udev-242, it is silently not considered during dependency solving by emerge.<br>
However, the PMS states:<br>
&nbsp;- it is an error for a use dependency to be applied to an ebuild which does not have the flag in question in <span class="ectt-1000">IUSE_REFERENCEABLE</span><br>
&nbsp;- For EAPIs listed in table&nbsp;<a href="https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-56001r4">5.4</a> as not supporting profile defined <span class="ectt-1000">IUSE </span>injection, <span class="ectt-1000">IUSE_REFERENCEABLE </span>is equal to the calculated <span class="ectt-1000">IUSE </span>value. For EAPIs where profile defined <span class="ectt-1000">IUSE </span>injection is supported, <span class="ectt-1000">IUSE_REFERENCEABLE </span>is equal to <span class="ectt-1000">IUSE_EFFECTIVE<br>
And 'static-libs' is not in the IUSE_EFFECTIVE of </span>sys-fs/udev-242 (that ebuild has EAPI=6).<br>
So it seems to me that this current behavior of emerge should be considered an error, no? Or the PMS should be updated?<br>
<br>
Best,<br>
Michael</div>

[-- Attachment #2: Type: text/html, Size: 1357 bytes --]

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Brian Dolbec]

On Tue, 16 Jun 2020 20:43:44 +0200 (CEST)
"michael.lienhardt" <michael.lienhardt@laposte.net> wrote:

> <div style="font-family:Arial, Helvetica, sans-serif;
> font-size:12px;">‌Dear all,<br> <br>
> My bad for not noticing it sooner, but when there is a dependency
> like "&gt;=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in
> virtual/libgudev-215-r3), since 'static-libs' is not a use flags of
> sys-fs/udev-242, it is silently not considered during dependency
> solving by emerge.<br> However, the PMS states:<br> &nbsp;- it is an
> error for a use dependency to be applied to an ebuild which does not
> have the flag in question in <span
> class="ectt-1000">IUSE_REFERENCEABLE</span><br> &nbsp;- For EAPIs
> listed in table&nbsp;<a
> href="https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-56001r4">5.4</a>
> as not supporting profile defined <span class="ectt-1000">IUSE
> </span>injection, <span class="ectt-1000">IUSE_REFERENCEABLE
> </span>is equal to the calculated <span class="ectt-1000">IUSE
> </span>value. For EAPIs where profile defined <span
> class="ectt-1000">IUSE </span>injection is supported, <span
> class="ectt-1000">IUSE_REFERENCEABLE </span>is equal to <span
> class="ectt-1000">IUSE_EFFECTIVE<br> And 'static-libs' is not in the
> IUSE_EFFECTIVE of </span>sys-fs/udev-242 (that ebuild has
> EAPI=6).<br> So it seems to me that this current behavior of emerge
> should be considered an error, no? Or the PMS should be updated?<br>
> <br> Best,<br> Michael</div>

Please do NOT send html emails.  text only please

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 1156 bytes --]

On 6/16/20 11:43 AM, 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
> virtual/libgudev-215-r3), since 'static-libs' is not a use flags of
> sys-fs/udev-242, it 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
>  - For EAPIs listed in table 5.4
> <https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-56001r4> as not
> supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal
> to the calculated IUSE value. For EAPIs where profile defined IUSE
> injection is supported, IUSE_REFERENCEABLE is equal to IUSE_EFFECTIVE
> And 'static-libs' is not in the IUSE_EFFECTIVE of sys-fs/udev-242 (that
> ebuild has EAPI=6).
> So it seems to me that this current behavior of emerge should be
> considered an error, no? Or the PMS should be updated?

It's valid as a 4-style dependency with use-dep-defaults.
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michael Lienhardt]

I'm sorry, my client didn't allow to send plain text email anymore...

So, here is my original email.

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 virtual/libgudev-215-r3),
 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
 - For EAPIs listed in table 5.4 as not supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value. For EAPIs where profile defined IUSE injection is supported, IUSE_REFERENCEABLE is equal to IUSE_EFFECTIVE
And 'static-libs' is not in the IUSE_EFFECTIVE of sys-fs/udev-242 (that ebuild has EAPI=6).
So it seems to me that this current behavior of emerge should be considered an error, no? Or the PMS should be updated?

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

Best,
Michael


On 6/16/20 7:42 PM, Brian Dolbec wrote:
> 
> Please do NOT send html emails.  text only please
> 

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 3476 bytes --]

On 6/16/20 6:38 PM, Michael Lienhardt wrote:
> 
> 
> On 6/16/20 9:31 PM, Zac Medico wrote:
>> On 6/16/20 11:07 PM, Michael Lienhardt wrote:
>>> I'm sorry, my client didn't allow to send plain text email anymore...
>>>
>>> So, here is my original email.
>>>
>>> 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 virtual/libgudev-215-r3),
>>>  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
>>>  - For EAPIs listed in table 5.4 as not supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value. For EAPIs where profile defined IUSE injection is supported, IUSE_REFERENCEABLE is equal to IUSE_EFFECTIVE
>>> And 'static-libs' is not in the IUSE_EFFECTIVE of sys-fs/udev-242 (that ebuild has EAPI=6).
>>> So it seems to me that this current behavior of emerge should be considered an error, no? Or the PMS should be updated?

Yes, according to PMS it's a "error" but emerge has never reported it as
such. Adding an error message to emerge sounds fine to me.

>>> 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)?
> 
>> It's valid as a 4-style dependency with use-dep-defaults.

Actually, it doesn't have use-dep-defaults but somehow my brain
associated it with that because you were talking about IUSE.

> I know. Except that in virtual/libgudev-215-r3.ebuild we have in the DEPEND:
>  >=sys-fs/udev-208-r1:0/0[${MULTILIB_USEDEP},gudev(-),introspection(-)?,static-libs?]
> It is a 2-style dependency (following the PMS).
> 
> I checked with 3 dummy packages
> 
> 1. app-misc/dummy-master-1
> EAPI=6
> SLOT=0
> KEYWORDS="amd64"
> IUSE="static-libs"
> DEPEND=">=app-misc/dummy-slave-1[static-libs?]"
> #DEPEND="=app-misc/dummy-slave-1[static-libs?]"
> 
> 2. app-misc/dummy-slave-1
> EAPI=6
> SLOT=0
> KEYWORDS="amd64"
> IUSE=""
> DEPEND=""
> 
> 3. app-misc/dummy-slave-2
> EAPI=6
> SLOT=0
> KEYWORDS="amd64"
> IUSE="static-libs"
> DEPEND=""
> 
> With the first version of DEPEND, emerge succeed:
> # emerge -pv app-misc/dummy-master
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild  N     ] app-misc/dummy-slave-2::gentoo  USE="-static-libs" 0 KiB
> [ebuild  N     ] app-misc/dummy-master-1::gentoo  USE="-static-libs" 0 KiB

This success is expected, yes? Do you suggest to change the behavior
somehow?

> With the second version of DEPEND, emerge fails:
> # emerge -pv app-misc/dummy-master
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> emerge: there are no ebuilds built with USE flags to satisfy "=app-misc/dummy-slave-1[static-libs?]".
> !!! One of the following packages is required to complete your request:
> - app-misc/dummy-slave-1::gentoo (Missing IUSE: static-libs)
> (dependency required by "app-misc/dummy-master-1::gentoo" [ebuild])
> (dependency required by "app-misc/dummy-master" [argument])

This failure is expected, yes? Do you suggest to change the behavior
somehow?
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Zac Medico]

[-- Attachment #1.1: Type: text/plain, Size: 2127 bytes --]

On 6/16/20 7:47 PM, Michael Lienhardt wrote:
> 
> 
> On 6/16/20 11:59 PM, Zac Medico wrote:
>> On 6/16/20 6:38 PM, Michael Lienhardt wrote:
>>> With the first version of DEPEND, emerge succeed:
>>> # emerge -pv app-misc/dummy-master
>>>
>>> These are the packages that would be merged, in order:
>>>
>>> Calculating dependencies... done!
>>> [ebuild  N     ] app-misc/dummy-slave-2::gentoo  USE="-static-libs" 0 KiB
>>> [ebuild  N     ] app-misc/dummy-master-1::gentoo  USE="-static-libs" 0 KiB
>>
>> This success is expected, yes? Do you suggest to change the behavior
>> somehow?
> 
> The way I interpret the PMS, this success is not expected:
>  the atom ">=app-misc/dummy-slave-1" matches the cpv "app-misc/dummy-slave-1" which does not contains the use flag 'static-libs',
>  and thus I expected a 'missing use flag' error.

For this calculation, it would be a waste of time to read the IUSE
metadata for app-misc/dummy-slave-1, since app-misc/dummy-slave-2 is the
highest available version.

I hope that PMS does not specify that package managers must read IUSE
metadata for irrelevant package versions!

> I'm not suggesting to change the behavior of emerge, I'm saying that:
>  - the way I read the PMS, I expect behavior A, but in practice, I see behavior B.
>  - what does the portage devs / PMS gurus think about that?
>     - is my understanding of the PMS wrong, and it actually says "behavior B is expected"?
>     - if yes, where did I fail in my understanding?
>     - if no, should emerge or the PMS be updated so they both describe the same behavior?
>  - I will implement your ruling in my tool, which I try to match as closely as possible to the PMS

In this context I think the spirit of what PMS says is that the package
manager should emit some kind of warning message if it finds missing
IUSE. Now, in the example above, if the package manager has no reason to
examine the IUSE metadata of app-misc/dummy-slave-1 because
app-misc/dummy-slave-2 is the highest available version, then there's no
opportunity for it to emit a warning message.
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michael Lienhardt]

On 6/16/20 9:31 PM, Zac Medico wrote:
> On 6/16/20 11:07 PM, Michael Lienhardt wrote:
>> I'm sorry, my client didn't allow to send plain text email anymore...
>> 
>> So, here is my original email.
>> 
>> 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 virtual/libgudev-215-r3),
>>  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
>>  - For EAPIs listed in table 5.4 as not supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value. For EAPIs where profile defined IUSE injection is supported, IUSE_REFERENCEABLE is equal to IUSE_EFFECTIVE
>> And 'static-libs' is not in the IUSE_EFFECTIVE of sys-fs/udev-242 (that ebuild has EAPI=6).
>> So it seems to me that this current behavior of emerge should be considered an error, no? Or the PMS should be updated?
>> 
>> 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)?

> It's valid as a 4-style dependency with use-dep-defaults.

I know. Except that in virtual/libgudev-215-r3.ebuild we have in the DEPEND:
 >=sys-fs/udev-208-r1:0/0[${MULTILIB_USEDEP},gudev(-),introspection(-)?,static-libs?]
It is a 2-style dependency (following the PMS).

I checked with 3 dummy packages

1. app-misc/dummy-master-1
EAPI=6
SLOT=0
KEYWORDS="amd64"
IUSE="static-libs"
DEPEND=">=app-misc/dummy-slave-1[static-libs?]"
#DEPEND="=app-misc/dummy-slave-1[static-libs?]"

2. app-misc/dummy-slave-1
EAPI=6
SLOT=0
KEYWORDS="amd64"
IUSE=""
DEPEND=""

3. app-misc/dummy-slave-2
EAPI=6
SLOT=0
KEYWORDS="amd64"
IUSE="static-libs"
DEPEND=""

With the first version of DEPEND, emerge succeed:
# emerge -pv app-misc/dummy-master

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] app-misc/dummy-slave-2::gentoo  USE="-static-libs" 0 KiB
[ebuild  N     ] app-misc/dummy-master-1::gentoo  USE="-static-libs" 0 KiB


With the second version of DEPEND, emerge fails:
# emerge -pv app-misc/dummy-master

These are the packages that would be merged, in order:

Calculating dependencies... done!

emerge: there are no ebuilds built with USE flags to satisfy "=app-misc/dummy-slave-1[static-libs?]".
!!! One of the following packages is required to complete your request:
- app-misc/dummy-slave-1::gentoo (Missing IUSE: static-libs)
(dependency required by "app-misc/dummy-master-1::gentoo" [ebuild])
(dependency required by "app-misc/dummy-master" [argument])



Michael

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michael Lienhardt]

On 6/16/20 11:59 PM, Zac Medico wrote:
> On 6/16/20 6:38 PM, Michael Lienhardt wrote:
>> With the first version of DEPEND, emerge succeed:
>> # emerge -pv app-misc/dummy-master
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>> [ebuild  N     ] app-misc/dummy-slave-2::gentoo  USE="-static-libs" 0 KiB
>> [ebuild  N     ] app-misc/dummy-master-1::gentoo  USE="-static-libs" 0 KiB
> 
> This success is expected, yes? Do you suggest to change the behavior
> somehow?

The way I interpret the PMS, this success is not expected:
 the atom ">=app-misc/dummy-slave-1" matches the cpv "app-misc/dummy-slave-1" which does not contains the use flag 'static-libs',
 and thus I expected a 'missing use flag' error.
I'm not suggesting to change the behavior of emerge, I'm saying that:
 - the way I read the PMS, I expect behavior A, but in practice, I see behavior B.
 - what does the portage devs / PMS gurus think about that?
    - is my understanding of the PMS wrong, and it actually says "behavior B is expected"?
    - if yes, where did I fail in my understanding?
    - if no, should emerge or the PMS be updated so they both describe the same behavior?
 - I will implement your ruling in my tool, which I try to match as closely as possible to the PMS

>> With the second version of DEPEND, emerge fails:
>> # emerge -pv app-misc/dummy-master
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>> emerge: there are no ebuilds built with USE flags to satisfy "=app-misc/dummy-slave-1[static-libs?]".
>> !!! One of the following packages is required to complete your request:
>> - app-misc/dummy-slave-1::gentoo (Missing IUSE: static-libs)
>> (dependency required by "app-misc/dummy-master-1::gentoo" [ebuild])
>> (dependency required by "app-misc/dummy-master" [argument])
> 
> This failure is expected, yes? Do you suggest to change the behavior
> somehow?

The way I interpret the PMS, this failure is expected.

I'm sorry if I'm not always clear, I try to be, and many thanks to take the time to answer my (unexpected and strange) questions.

Best,
Michael

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

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 virtual/libgudev-215-r3),
>  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 '(+)'.

> 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.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

>>>>> On Wed, 17 Jun 2020, Michael Lienhardt wrote:

> But maybe, "error" here in the PMS mean "the cpvs without the use flag
> does not match that dependency and a warning should be raised to
> improve compatibility in the future". In that case, it would be
> clearer for me to change 'error' in the PMS into something like
> "results in a no match,

IMHO we cannot assume that. If the flag is not in the dependency's
IUSE_EFFECTIVE then behaviour is undefined.

> but should be avoided". That way, it is explicitly stated that missing
> use flags for a 2-style USE dependency is accepted (which is the
> current behavior of emerge) but frown upon, without forcing any
> specific error handling, like Michał accurately pointed out.

The real problem is that we don't have a good procedure for removing
flags from ebuilds with reverse (2-style) use dependencies. (And even
with 4-style use dependencies the problem remains that one cannot know
in advance whether removal of the flag implies that the feature is now
unconditionally enabled, or that it is disabled.)

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michael Lienhardt]

On 6/17/20 1:25 AM, Zac Medico wrote:
> On 6/16/20 7:47 PM, Michael Lienhardt wrote:
>>
>>
>> On 6/16/20 11:59 PM, Zac Medico wrote:
>>> On 6/16/20 6:38 PM, Michael Lienhardt wrote:
>>>> With the first version of DEPEND, emerge succeed:
>>>> # emerge -pv app-misc/dummy-master
>>>>
>>>> These are the packages that would be merged, in order:
>>>>
>>>> Calculating dependencies... done!
>>>> [ebuild  N     ] app-misc/dummy-slave-2::gentoo  USE="-static-libs" 0 KiB
>>>> [ebuild  N     ] app-misc/dummy-master-1::gentoo  USE="-static-libs" 0 KiB
>>>
>>> This success is expected, yes? Do you suggest to change the behavior
>>> somehow?
>>
>> The way I interpret the PMS, this success is not expected:
>>  the atom ">=app-misc/dummy-slave-1" matches the cpv "app-misc/dummy-slave-1" which does not contains the use flag 'static-libs',
>>  and thus I expected a 'missing use flag' error.
> 
> For this calculation, it would be a waste of time to read the IUSE
> metadata for app-misc/dummy-slave-1, since app-misc/dummy-slave-2 is the
> highest available version.

Good point.
I changed the version of app-misc/dummy-slave-1 into app-misc/dummy-slave-3 (so now the higher version is the one without the 'static-libs' use flag), and still no error/warning message.

> I hope that PMS does not specify that package managers must read IUSE
> metadata for irrelevant package versions!

I think there is indeed an ambiguity there:
 Section 8.3 of the PMS states when a cpv matches an atom, but does not say which cpvs should be tested against an atom during dependency analysis.
This is where my interpretation was maybe wrong: when I see "error" in Section 8.3.4 I understand
 "all cpv matching an atom with this 2-style USE dependency *must* have the use flag declared, otherwise
 the .ebuild should be considered erroneous" (I have a strong notion of error).
I thus thought that all .ebuilds in the distributed repos were checked (before distribution -- not by emerge) against that error.

But maybe, "error" here in the PMS mean "the cpvs without the use flag does not match that dependency and a warning should be raised to improve compatibility in the future".
In that case, it would be clearer for me to change 'error' in the PMS into something like "results in a no match, but should be avoided".
That way, it is explicitly stated that missing use flags for a 2-style USE dependency is accepted (which is the current behavior of emerge) but frown upon,
 without forcing any specific error handling, like Michał accurately pointed out.


>> I'm not suggesting to change the behavior of emerge, I'm saying that:
>>  - the way I read the PMS, I expect behavior A, but in practice, I see behavior B.
>>  - what does the portage devs / PMS gurus think about that?
>>     - is my understanding of the PMS wrong, and it actually says "behavior B is expected"?
>>     - if yes, where did I fail in my understanding?
>>     - if no, should emerge or the PMS be updated so they both describe the same behavior?
>>  - I will implement your ruling in my tool, which I try to match as closely as possible to the PMS
> 
> In this context I think the spirit of what PMS says is that the package
> manager should emit some kind of warning message if it finds missing
> IUSE. Now, in the example above, if the package manager has no reason to
> examine the IUSE metadata of app-misc/dummy-slave-1 because
> app-misc/dummy-slave-2 is the highest available version, then there's no
> opportunity for it to emit a warning message.

From what I've seen now, emerge considers a 2-style USE dependency error as a "no match without warning message", and fails with my second version of DEPEND because there are no .ebuild matching the dependency: the error message it issues only describes why there is no solution, it is not a warning about an erroneous dependency.

Best,
Michael

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michael Lienhardt]

Le 17/06/2020 à 10:35, Ulrich Mueller a écrit :
>>>>>> On Wed, 17 Jun 2020, Michael Lienhardt wrote:
> 
>> But maybe, "error" here in the PMS mean "the cpvs without the use flag
>> does not match that dependency and a warning should be raised to
>> improve compatibility in the future". In that case, it would be
>> clearer for me to change 'error' in the PMS into something like
>> "results in a no match,
> 
> IMHO we cannot assume that. If the flag is not in the dependency's
> IUSE_EFFECTIVE then behaviour is undefined.

Fair enough.
However, currently the PMS says it is an error, not an undefined behavior.

>> but should be avoided". That way, it is explicitly stated that missing
>> use flags for a 2-style USE dependency is accepted (which is the
>> current behavior of emerge) but frown upon, without forcing any
>> specific error handling, like Michał accurately pointed out.
> 
> The real problem is that we don't have a good procedure for removing
> flags from ebuilds with reverse (2-style) use dependencies. (And even
> with 4-style use dependencies the problem remains that one cannot know
> in advance whether removal of the flag implies that the feature is now
> unconditionally enabled, or that it is disabled.)

Indeed.
This is outside the scope of my original question, but intuitively, I 
would imagine that the devs should know why they remove a use flag. It's 
just an idea, but I see two possibilities.
1. either the change is temporary: in that case, they could keep the use 
flag and set its value in REQUIRED_USE during that period
2. either the change is durable: in that case, it is still possible to 
keep the use flag (while still setting its value in REQUIRED_USE) during 
a period of time during which it is possible to update the dependencies 
toward that package (the use flag would become deprecated before being 
removed).
That way, enforcing the error described in the PMS would be telling to 
the devs that they didn't update their dependencies during the 
transition period.

Best,
Michael

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Michael Lienhardt]

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 virtual/libgudev-215-r3),
>>   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).

Best,
Michael