Re: pkg/59530 (Ports: lsof : The Operating System version (10.1) does not match 10.0)

["David H. Gutteridge via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR pkg/59530; it has been noted by GNATS.

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/59530 (Ports: lsof : The Operating System version (10.1)
 does not match 10.0)
Date: Mon, 25 Aug 2025 20:04:46 -0400

 On Sun, 24 Aug 2025 at 02:48:05 +0000, John L. Males wrote:
 > Hello,
 >=20
 >  Sorry, but few more bugs not reported have occurred further
 >  distracting time need to organized pkgin bug report wiping out my
 >  NetBSD system as noted prior.
 >=20
 >  The suggestion related to this bug:
 >=20
 >  > You have two options here. One is to simply follow the
 >  > instructions in the message, that is, "add CHECK_OSABI=3Dno to
 >  > pkg_install.conf". That should be safe to do in this context
 >  > (with this package). The other is to build the package from
 >  > source instead. (That brings its own not recommended approach of
 >  > mixing binary and locally-built packages, but is relatively
 >  > simple for this particular example.)
 >=20
 >  Raises these concerns:
 >=20
 >  1) Assuming "add" "CHECK_OSABI=3Dno" is added to "pkg_install.conf"
 >  "should be safe" is safe then raises the possibility that other
 >  package(s) that would otherwise have issue(s) and may not be safe
 >  with "add CHECK_OSABI=3Dno" in the "pkg_install.conf".
 >=20
 >  2) This is even more complicated if a package installing via pkgin
 >  does not need "CHECK_OSABI=3Dno" in "pkg_install.conf", but one or
 >  more required packages needed to install requested package would
 >  where one or more of those required packages is not safe to install
 >  with "CHECK_OSABI=3Dno" in "pkg_install.conf".
 
 Yes, though there are over 29,000 packages in pkgsrc. There are
 presently only ten actual packages that set OSVERSION_SPECIFIC (plus
 one that is for build-only purposes, x11-links).
 
 benchmarks/hbench/Makefile:20:OSVERSION_SPECIFIC=3D	YES
 devel/p5-perl-headers/Makefile:20:OSVERSION_SPECIFIC=3D	yes
 devel/debugcon_printf/Makefile:14:OSVERSION_SPECIFIC=3D	YES
 emulators/haxm/Makefile:14:OSVERSION_SPECIFIC=3D	YES
 lang/STk/Makefile:16:OSVERSION_SPECIFIC=3D	yes
 net/net-snmp/Makefile:30:OSVERSION_SPECIFIC=3D	YES
 net/oidentd/Makefile:18:OSVERSION_SPECIFIC=3D	YES
 pkgtools/x11-links/Makefile:29:OSVERSION_SPECIFIC=3D	yes
 sysutils/libgtop/Makefile:14:OSVERSION_SPECIFIC=3D	YES
 sysutils/lsof/Makefile:24:OSVERSION_SPECIFIC=3D	yes
 sysutils/pftop/Makefile:16:OSVERSION_SPECIFIC=3D	yes
 
 (Of these, libgtop has the biggest potential footprint, since it gets
 pulled in by the gnome and mate meta-packages. Most of these are leaf
 packages that won't be pulled in by anything else.)
 
 This is one reason why this topic hasn't seen any attention. No one
 has touched the related mk infrastructure in about fifteen years.
 
 >  3) Clearly the other option to build from package source implies
 >  many possible issues with package compatibility to binary packages
 >  installed with pkgin.  This sounds like will will lead to all
 >  sorts of problems short and long term.  I know this first hand
 >  having built major package from source that then wants this
 >  "different" version of package(s) that then leads to many more
 >  packages that have to be built, and repeat often many times thatat
 >  times means one basically has to rebuild almost all packages from
 >  source.
 
 lsof has no true binary dependencies on other pkgsrc packages. It only
 links against libraries in the base system. So there is no concern here
 for this package. (That's what I meant before by "relatively simple",
 though I realize that wasn't clear.)
 
 /usr/pkg/sbin/lsof:
 	-lutil.7 =3D> /usr/lib/libutil.so.7
 	-lc.12 =3D> /usr/lib/libc.so.12
 	-lkvm.6 =3D> /usr/lib/libkvm.so.6
 
 (There could potentially be concern with #1 above, of course.)
 
 It does "depend" on perl, but that is only because it comes with
 example scripts that wrap "lsof" calls inside scripting.
 
 >  4) So far it appears there is no way to just build the package as
 >  binary for pkgin to install such that something like (2) or results
 >  from (3) does not need to be done to do so, prevent need for
 >  complications of (3), and not need "alternate" (3) and many issues
 >  can result in short and long term.=20
 
 Yes, well, to me there's more than one topic here. One is that you seem
 to want to use lsof immediately. The options mentioned are your choices.
 Realistically, it's not likely the broader OSABI item will get attention
 any time soon, nor will TNF be building different binary packages for
 each "minor" release given they should all be binary compatible in
 actuality. People have discussed the broader topic internally, and
 indeed questioned whether several of the packages that set
 OSVERSION_SPECIFIC should really do so, but so many packages, so little
 time is often the name of the game, unfortunately.
 
 Regards,
 
 Dave