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
