erroneous behavior in 2-style USE dependencies?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

erroneous behavior in 2-style USE dependencies?

Michael Lienhardt
‌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 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?

Best,
Michael
Reply | Threaded
Open this post in threaded view
|

Re: erroneous behavior in 2-style USE dependencies?

Brian Dolbec-3
On Tue, 16 Jun 2020 20:43:44 +0200 (CEST)
"michael.lienhardt" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: 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
>

Reply | Threaded
Open this post in threaded view
|

Re: erroneous behavior in 2-style USE dependencies?

Zac Medico-2
In reply to this post by Michael Lienhardt
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


signature.asc (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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

Reply | Threaded
Open this post in threaded view
|

Re: erroneous behavior in 2-style USE dependencies?

Zac Medico-2
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


signature.asc (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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

Reply | Threaded
Open this post in threaded view
|

Re: erroneous behavior in 2-style USE dependencies?

Zac Medico-2
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


signature.asc (1000 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: erroneous behavior in 2-style USE dependencies?

Michał Górny-5
In reply to this post by Michael Lienhardt
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


signature.asc (631 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: erroneous behavior in 2-style USE dependencies?

Michael Lienhardt
In reply to this post by Zac Medico-2


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

Reply | Threaded
Open this post in threaded view
|

Re: erroneous behavior in 2-style USE dependencies?

Ulrich Mueller-2
>>>>> 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

signature.asc (517 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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

Reply | Threaded
Open this post in threaded view
|

Re: erroneous behavior in 2-style USE dependencies?

Michael Lienhardt
In reply to this post by Michał Górny-5


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