Thoughts on osabi

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

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?

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!


Best regards,

Kyeong Ro