Re: Thoughts on osabi

[Kyeong Ro Lee <kyeongro%icloud.com@localhost>]

Hello all,

many thanks for your feedback and sorry for coming back to this topic so 
late. It did take me quite some time to research this topic further and 
read the past problem reports.


> > > It's a little more complicated. Stable major branches are not supposed
> > > to break ABI compatibility, which is why you see 10.0 and 10.1 (for
> > > example) getting the same binary packages. However, unstable releases
> > > can deliberately break ABI compatibility (within x.99.x iterations).
> > What if we evolve osabi to take these rules into account? That is, for NetBSD _only_, do the following:
> >
> > - osabi built on any 10.x release (from 10.0_RC1 to 10.2_STABLE, etc.) just becomes "10".
> > - For a 10.99.x release, we continue recording the entire version number.
> > - pkg_install would use the same rules to CHECK_OSABI
> >
> > I can understand a desire to avoid special cases, but this is the native packaging system for NetBSD, so we can be aware of the special rules for NetBSD versioning.
> >
> > Any comments or objections?
> >
> > --
> > Benny

Thanks for pointing out the problem with the unstable branch (x.99.y), 
which I had not taken into consideration.

I have tested this patch:

Index: mk/bsd.prefs.mk
===================================================================
RCS file: /cvsroot/pkgsrc/mk/bsd.prefs.mk,v
retrieving revision 1.463
diff -u -p -r1.463 bsd.prefs.mk
--- mk/bsd.prefs.mk    13 Apr 2026 15:43:03 -0000    1.463
+++ mk/bsd.prefs.mk    28 Jul 2026 22:29:29 -0000
@@ -160,6 +160,10 @@ MACHINE_GNU_ARCH?= ${GNU_ARCH.${MACHINE
 ## If changes are made to how OS_VERSION is set below please keep
 ## "pkgsrc/pkgtools/osabi/INSTALL" in-sync.
 .if ${NATIVE_OPSYS} == "NetBSD"
+# Assume x.0 for stable branches
+.  if ${NATIVE_OS_VERSION:C/[0-9]*\.([0-9]*).*/\1/} < 99
+NATIVE_OS_VERSION:= ${NATIVE_OS_VERSION:C/([0-9]*\.).*/\10/}
+.  endif
 NATIVE_LOWER_OPSYS?=    netbsd

 # Ensure HOST_MACHINE_ARCH is set for native-but-compat builds, such as
Index: pkgtools/osabi/INSTALL
===================================================================
RCS file: /cvsroot/pkgsrc/pkgtools/osabi/INSTALL,v
retrieving revision 1.7
diff -u -p -r1.7 INSTALL
--- pkgtools/osabi/INSTALL    24 Jul 2022 20:56:56 -0000    1.7
+++ pkgtools/osabi/INSTALL    28 Jul 2026 22:30:14 -0000
@@ -12,6 +12,12 @@ PRE-INSTALL)
     OS_VERSION=`${UNAME} -r`
     PKG_VERSION="${PKGNAME##*-}"
     case `${UNAME} -s` in
+    NetBSD)
+        OS_VERSION=`echo "${OS_VERSION}" | \
+            awk -F. '{ split($2, minor, "_"); \
+                if (minor[1] >= 99) print; \
+                else printf "%d%s%d\n", $1, FS, 0 }'`
+        ;;
     AIX)
         if ${TEST} -f /usr/bin/oslevel ;then
             OS_VERSION=`/usr/bin/oslevel | \


But if this is true:

> IIUC, packages built for 10.0 can run on 10.2 but packages built on
> 10.2 might not run on 10.0. So we couldn’t just equate 10.0 and 10.2.

then the patch I've suggested above is perhaps a no-go? In the PR #59530 
(https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=59530) Dave 
mentioned

> TNF binary packages are built to match any major version, against the
> earliest release (10.0 in this case), so this will trigger the mismatch
> error by design.

Maybe this is what Rob meant? This raises then another question: are the 
binary packages such as lsof still being built specifically for 10.0, 
not 10.1, even though 10.1 has been there for quite a long time?

Are the official build hosts then still running 10.0 for compatibility 
reasons (as upgrading them to 10.1 would potentially make some packages 
built on them unable to run on 10.0 machines)? Or is it possible to 
build packages targeted for 10.0 on a build host running 10.1?

For 11.0, I guess the official build hosts must have been running 
11.0_RC* (or some development snapshot for 11) for many months, because 
11.0 was released just last week. If I understood Rob correctly, this 
should be fine as the packages are expected to be forward-compatible?


If it is this complicated, then is this option

> https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=52325
> (Discusses the idea of binary packages per minor release for the
> subset that this affects. Nothing's ever been spun up to do this.)
the only way to go?


Best regards,

Kyeong Ro