Re: Thoughts on osabi

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

On Fri, 29 May 2026 at 18:14:48 +0200, Kyeong Ro Lee wrote:
> Hello NetBSD community!
> 
> 
> I have been using NetBSD/i386 for a couple of months and would like to
> discuss the osabi dummy package a little bit.
> 
> 
> I started with 11.0_RC2, then upgraded to 11.0_RC3 and 11.0_RC4.
> 
> As most of you already know, pkgin fails to install certain binary
> packages such as libgtop or x11-links if the osabi-NetBSD package is
> not properly installed. The osabi-NetBSD package complains that "The
> Operating System version (11.0_RC2) does not match 11.0". And yes, I
> know that setting CHECK_OSABI=no in /etc/pkg_install.conf "fixes" the
> problem, which in fact skips the entire pre-install check in the
> INSTALL script in pkgtools/osabi.
> 
> 
> After experiencing the same problem on NetBSD 10.1, I concluded that
> most users who just use binary packages are virtually "required" to
> set CHECK_OSABI=no from the beginning, as the version check would fail
> for the most of the time in each version's life cycle (i.e. 11.0_RC1 -
> 11.0_RC2 - ... - 11.0 - 11.1 - 11.2 - ...). This is because pkgsrc has
> its own quarterly release cycle and the binary packages are built only
> for versions n.0 (e.g. 9.0, 10.0 and 11.0). I have checked the
> directories for 9.4 and 10.1 are just symlinks to 9.0_2026Q1 and
> 10.0_2026Q1.
> 
> 
> To better understand how this ABI check works I tried building some of
> the packages locally. On 11.0_RC4 the osabi package is installed as
> "osabi-NetBSD-11.0_RC4" when locally built. I modified the PKGNAME
> variable in pkgtools/osabi/Makefile such that the package is installed
> as "osabi-NetBSD-11.0", dropping the "_RC4" part. This causes the x11-
> links package to fail to build, as it requires "osabi-NetBSD-
> 11.0_RC4", not "osabi-NetBSD-11.0". To relax this strict requirement,
> I modified the NATIVE_OS_VERSION variable in mk/bsd.prefs.mk to
> truncate the "_RC4" part from the OS version. Now the x11-links
> package requires "osabi-NetBSD-11.0" and the build succeeds.
> 
> 
> Let me give one example where the current osabi scheme makes things
> complicated. What if I would like to install one package requiring
> osabi using pkgin (i.e. as binary), but build another package that
> also requires osabi? Having both osabi-NetBSD-11.0 (as required by the
> binary package) and osabi-NetBSD-11.0_RC4 (as required by the locally
> built package) won't be possible (is it?). Or is it generally not
> recommended to install both binary packages and locally built packages
> under the same LOCALBASE (/usr/pkg)? By building packages locally I
> don't necessarily mean actively participating in the package
> development, but rather what Gentoo users typically do.
> 
> 
> I came to doubt if it's important to strictly distinguish between
> minor upgrades (11.0_RC* or 11.1, 11.2, ...) within a certain major
> version. Currently the binary packages are provided without such
> strict distinction anyway. Are the binary packages for 10.0 indeed
> built for 10.0, or actually 10.1 at the moment? If they are built
> exactly for 10.0, would they be always like that even if, say, 10.5 is
> out there? What about 11.0? Are these binary packages built for the
> not-yet-existent (therefore not-yet-precisely-defined) 11.0 release?

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).

There's the added complication that osabi is arguably abused to
represent/handle cases it shouldn't. x11-links is really about what
state X source is in, not anything else, yet the two get conflated.
(There was an attempt to switch to be concerned with the userland side,
but that also broke stuff. Really we need two packages, it seems.)

This has also been discussed in various bug reports (not sure anyone
really wants to wade through them), e.g.,

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.)

https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=59530
(Just another example of discussion.)

> If the minor version upgrade could indeed break the ABI compatibility
> and hence the version check may not be relaxed, the users would
> typically have two choices. Either always set CHECK_OSABI=no and use
> (potentially incompatible) binary packages at their own risk (i.e.
> convenience at the expense of consistency), or always build packages
> that mandate the ABI check on their own, since pkgsrc doesn't provide
> separate binary packages for each minor revision. It seems users tend
> to be advised to take the former approach.
> 
> 
> If minor revisions do not change the ABI, I'd make these changes:
> 
>  - mk/bsd.prefs.mk first processes the result of 'uname -r' instead of
> directly using it. It would happen either around ln. 164 by redefining
> NATIVE_OS_VERSION in the NetBSD case or ln. 361 by changing the
> definition of OS_VERSION. The result would be that the packages have
> dependency on osabi-NetBSD-n.0.
> 
> 
>  - pkgtools/osabi/Makefile then automatically sets the package version
> to osabi-NetBSD-n.0, regardless of the RC postfix or minor revision
> like n.1. No change is needed here.
> 
> 
>  - pkgtools/osabi/INSTALL compares this modified version number
> against OS_VERSION defined in ln. 12, but change its definition as
> well such that the result of 'uname -r' is piped to sed.
> 
> 
> 
> I know bringing this topic up might be a recurrent nuisance, so I have
> already checked previous threads about osabi in this mailing list:
> 
> 
> https://mail-index.netbsd.org/pkgsrc-users/2011/01/28/msg013620.html
> 
> https://mail-index.netbsd.org/pkgsrc-users/2015/10/12/msg022415.html
> 
> https://mail-index.netbsd.org/pkgsrc-users/2016/08/02/msg023589.html
> 
> https://mail-index.netbsd.org/pkgsrc-users/2023/02/06/msg036886.html
> 
> https://mail-index.netbsd.org/pkgsrc-users/2024/09/21/msg040231.html
> 
> At least in this mailing list I couldn't find a satisfactory answer.
> I'd appreciate your comments and opinions!

You're right, there really has never been a satisfactory answer.


Regards,

Dave