Re: plist-check not reporting orphaned files present in a @comment

I would like to confirm, plist-check is correct for make check-plist (or check-orphans), right?

It is run by Mk/Scripts/check-stagedir.sh, and from looking at it's contents, it appears that some patterns are not reported as orphans.
In the function check_orphans_from_plist(), they are lined up as a patterns of case.
It doesn't match the pattern, does it?

The following is just a quote attached.
Regards.


Felix Palmen wrote on 2023/08/18 03:00:
> * Tatsuki Makino <tatsuki_makino@hotmail.com> [20230817 17:14]:
>> Felix Palmen wrote on 2023/08/17 15:03:
>>> I might try another workaround, e.g. expand to "@comment dummy/"
>>> instead, so the name won't match and plist-check will complain ...
>>
>> epson-inkjet-printer-escpr2 is easy because it is restricted to 2 architectures, but in general it seems difficult.
>> How about also making a combined PLIST_SUB in Makefile?
> 
> JFTR, this wasn't my problem here. In my concrete scenario, there are
> only 3 supported archs anyways (I'm building a Linux-native toolchain
> from source for the Linuxulator, will present it on this list once it
> works on all 3 archs), and I already define NO_* subs, so it's straight
> forward to set anything that might be required in pkg-plist.
> 
> The issue really was just about plist-check, which will *not* report
> "orphaned" files when they are present in some @comment...
> 
> I now got around the issue using *this* block in my ports:
> 
> #v+
> .include <bsd.port.options.mk>
> 
> .if ${ARCH} == amd64
> PLIST_SUB+=     AMD64="" NO_AMD64="@comment _nonexisting/"
> .else
> PLIST_SUB+=     AMD64="@comment _nonexisting/" NO_AMD64=""
> .endif
> .if ${ARCH} == aarch64
> PLIST_SUB+=     AARCH64="" NO_AARCH64="@comment _nonexisting/"
> .else
> PLIST_SUB+=     AARCH64="@comment _nonexisting/" NO_AARCH64=""
> .endif
> .if ${ARCH} == i386
> PLIST_SUB+=     I386="" NO_I386="@comment _nonexisting/"
> .else
> PLIST_SUB+=     I386="@comment _nonexisting/" NO_I386=""
> .endif
> #v-
> 
> Sure, it's somewhat dirty workaround, but adding some "dummy" prefix to
> the files makes sure plist-check will complain about them ;)
>