On Fri, Nov 07, 2025 at 10:52:05PM -0500, George Koehler wrote:
> pkg_create has some code to check every @lib in a PLIST is correctly
> versioned (by expanding ${LIBname_VERSION}).  This check is broken, so
> the error never happens.  The broken code will cause a warning in
> Perl 5.42, so we must change it before we update Perl.
> 
> When I fixed the check, it broke a few ports,
> 
> $ make -C lang/vala print-plist-all >/dev/null                        
> Error: Incorrectly versioned shared library: \
> @lib lib/libvala-${API_V}.so.${LIBvala-${API_V}_VERSION}
> 
> This @lib line is correct, but pkg_create looked for the exact string
> '${LIBvala-0.56_VERSION}' in the unsubstituted line, and didn't find
> it, because API_V=0.56 was unsubst.  There are more than 30 ports like
> this; see list below diff.  (Because print-plist-all can produce the
> error, I didn't need a bulk build to find the broken ports.)
> 
> I want to commit this version of the diff, which has '0 &&' to disable
> the check, so ports like lang/vala don't break.  The other changes in
> this diff are,
>  - Change "!$x =~ m/y/" to "$x !~ m/y/", which fixes the Perl 5.42
>    warning "Possible precendence problem between ! and =~".
>  - Add \Q and \E to the regexp, so libestdc++ stops matching
>    '${LIBestdcccccc_VERSION}'.
>  - Pass the unsubstituted string to check_version: the caller did
>    "my $s = $subst->do($l);", so pass $l, not $s.
> 
> In the future, we might modify and enable this check.  For example, we
> might compare libvala's filename's version with LIBvala-0.56_VERSION,
> without looking for '${LIBvala-0.56_VERSION}'.  This might work for
> devel/libtalloc,-python which has,
> 
> @lib lib/libpytalloc-util.${PYTALLOC_UTIL_LIBSUFFIX}
> 
> We can't enable a check now, because cad/qcad has lines like,
> 
> @lib share/qcad/plugins/script/libqtscript_core.so.1.0
> 
> There is no LIBqtscript_core_VERSION=1.0; and I'm not sure whether to
> add these plugins to SHARED_LIBS or change them from @lib to @so.
> 
> Is this diff with '0 &&' ok?
> --gkoehler

No.

Andrew has had a patch to fix the warning for ages by now.

And the ports that do not have proper lib version naming should be fixed
anyway.

There is a reason we want to take control of shared libs version and the
fact that this check got broken is no reason to disable it.