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