Re: wifi-firmware-kmod-release-20241017 is not a unique package name; wifi-firmware-kmod-20241017 also is not

From: Bjoern A. Zeeb <bz_at_freebsd.org>
Date: Wed, 18 Dec 2024 19:20:04 UTC
On Wed, 18 Dec 2024, Mark Millard wrote:

> On Dec 18, 2024, at 10:55, Bjoern A. Zeeb <bz@freebsd.org> wrote:
>
>> On Wed, 18 Dec 2024, Mark Millard wrote:
>>
>>> On Dec 18, 2024, at 10:12, Bjoern A. Zeeb <bz@freebsd.org> wrote:
>>>
>>>> On Wed, 18 Dec 2024, Mark Millard wrote:
>>>>
>>>> Hi Mark, ports@,
>>>>
>>>>> As an example context, I am referencing:
>>>>>
>>>>> https://pkg-status.freebsd.org/ampere2/build.html?mastername=main-armv7-default&build=peb87cb7f3aa2_s48d92db080
>>>>>
>>>>> which is showing wifi-firmware-kmod-release-20241017 2 times in Ignored ports:
>>>>>
>>>>> # Package Origin Skipped Reason
>>>>> 1623 wifi-firmware-kmod-release-20241017 net/wifi-firmware-kmod@release 0 Dependent port net/wifi-firmware-iwlwifi-kmod@8000 | wifi-firmware-iwlwifi-kmod-8000-20241017.1500029_1 ignored
>>>>> 1629 wifi-firmware-kmod-release-20241017 net/wifi-firmware-kmod@release 0 Dependent port net/wifi-firmware-iwlwifi-kmod@22000 | wifi-firmware-iwlwifi-kmod-22000-20241017.1500029_1 ignored
>>>>
>>>> Funny.  I'd expect it to try all or just the furst dependency and if
>>>> that gets ingnored then to also ignore the rest right away.
>>>> Parallel built problems in pourdierer?
>>>
>>> I'll use the log file context to try a different wording to try to make
>>> clear what I'm reporting. I'm also CC'ing Bryan Drewery so he can cross
>>> check if I'm just wrong about something.
>>>
>>>>
>>>>> I'll note that here is only one:
>>>>>
>>>>> https://pkg-status.freebsd.org/ampere2/data/main-armv7-default/peb87cb7f3aa2_s48d92db080/logs/wifi-firmware-kmod-release-20241017.log
>>>>>
>>>>> and it is for the net/wifi-firmware-iwlwifi-kmod@22000 when looking at its content. I appears that log file content replaced the earlier content for net/wifi-firmware-iwlwifi-kmod@8000 (because of the lack of a unique log file name).
>>>>
>>>> Are you saying "unique log file name" here as the port name is distinct
>>>> with the name of the flavor?
>>>
>>> As I understand things, package names for a flavor are supposed to indicate the flavor
>>> explicitly in some way: such a one-to-one correspondence is required as I understand
>>> things.
>>>
>>> net/wifi-firmware-iwlwifi-kmod@8000  is using the package name: wifi-firmware-kmod-release-20241017
>>> also:
>>> net/wifi-firmware-iwlwifi-kmod@22000 is using the package name: wifi-firmware-kmod-release-20241017
>>>
>>> The 2 flavors have the same package name.
>>
>> No.  They are both child packages of the metport pacakge.
>>
>> The metaport has two flavours by the names:
>>
>> wifi-firmware-kmod-NNNNNNNN
>> wifi-firmware-kmod-release-NNNNNNNN
>>
>> The metaport package depends on ports with multiple flavours.
>> Have a look here:
>> https://cgit.freebsd.org/ports/tree/net/wifi-firmware-kmod/Makefile
>>
>> So for example the port:
>> net/wifi-firmware-iwlwifi-kmod
>> has flavours:
>> 7000
>> 8000
>> 9000
>> 22000
>> ax210
>> bz
>> which then individually expand to package names like:
>> wifi-firmware-iwlwifi-kmod-FLAVOUR-MMMMMMMMM
>> with FLAVOUR being one of the above and MMMMMMMM being the version of the
>> iwlwifi firmware.  And then there is a verions without the -FLAVOUR in
>> the middle which contains all of the iwlifi firmware which is the
>> default target for net/wifi-firmware-iwlwifi-kmod -- which the metaport
>> does not depend on so you are not seeing it there.
>>
>> Same goes for rtw88, rtw89, ath1[012]k, mt76.
>>
>> So it's a tree you are looking at.
>>
>> Very much like the gpu-firmware port for example.
>
> https://docs.freebsd.org/en/books/porters-handbook/flavors/
>
> reports:
>
> QUOTE
> Example 4. Flavor Specific PKGNAME
> As all packages must have a different package name, flavors must change theirs, using flavor_PKGNAMEPREFIX and flavor_PKGNAMESUFFIX makes this easy:
> FLAVORS= normal lite
> lite_PKGNAMESUFFIX= -lite
> END QUOTE
>
> Note the "must". The combination:
>
> net/wifi-firmware-iwlwifi-kmod@8000  is using the package name: wifi-firmware-kmod-release-20241017
> also:
> net/wifi-firmware-iwlwifi-kmod@22000 is using the package name: wifi-firmware-kmod-release-20241017
>
> This is via:
>
> BASEDIR=        ${.CURDIR}/../wifi-firmware-kmod
> . . .
> .include "${BASEDIR}/Makefile.inc"
>
> That in turn uses:

No!  Makefile.inc != Makefile


> PORTNAME=       wifi-firmware-kmod
> . . .
> FLAVORS=        default release
> release_PKGNAMESUFFIX=  -release
>
> that ignores the @8000 and @2200 but can not validly do so under the wording.
>
> Poudriere itself is reporting the actual pack name in use for
> both is: wifi-firmware-kmod-release-20241017
>
> I think we just need to wait for Bryan D. to comment about which of us
> is correct for the interpretation.
>
> I will say that if you are correct, poudriere depends on using package
> names inappropriately, such as that destruction of the log file for
> one flavor by the log file for another flavor that uses the same package
> name (since only the package naming was used in forming the log file name).
>
>>
>>> An example of the consequences:
>>>
>>> Go try to find a log file in:
>>>
>>> https://pkg-status.freebsd.org/ampere2/data/main-armv7-default/peb87cb7f3aa2_s48d92db080/logs/
>>>
>>> for the check of:
>>>
>>> net/wifi-firmware-iwlwifi-kmod@8000
>>>
>>> There is not one. That is because the package name does not indicate the flavor
>>> at all and that in turn means that the log file name does not contain a reference
>>> to the flavor name and the second check replace's the first check's file.
>>>
>>> As I understand it, poudriere's infrastructure does not support having multiple
>>> flavors of a port contributing to the same package for the port (by name).
>>>
>>>> . . .
>>>
>>> Please ignore the Skipped ports part of my report.
>>>
>>>> Those dependency packages for wifi-firmware-kmod-NNNNNNNN respectively
>>>> wifi-firmware-kmod-release-NNNNNNNN are not built for armv7:
>>>>
>>>> Makefile.inc:ONLY_FOR_ARCHS=    aarch64 amd64 i386
>>>>
>>>> so hopefully the "parent" (metaport) gets skipped as well once the first
>>>> one "fails" with the IGNORE.
>>>>
>>>>
>>>> If pourdierer does not fully grasp it, so be it.  The port names are
>>>> unique with the two flavours there are within the ports framework.
>>>> I'd expect you'd have to file a pourdriererer bug then?
>>>>
>>>>
>>>> Otherwise if I get this entirely wrong, can you please explain it more
>>>> precisely?
>>
>>                                                   r15:7
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>

-- 
Bjoern A. Zeeb                                                     r15:7