Re: CVS commit: pkgsrc/pkgtools/osabi

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

On Sun, 24 Jul 2022 at 20:59:58 +0000, nia wrote:

> On Sun, Jul 24, 2022 at 10:27:35AM -0400, Greg Troxel wrote:
> > 
> > Joerg Sonnenberger <joerg%bec.de@localhost> writes:
> > 
> > > On Sun, Jul 24, 2022 at 07:28:09AM +0000, Nia Alarie wrote:
> > >> Module Name:       pkgsrc
> > >> Committed By:      nia
> > >> Date:              Sun Jul 24 07:28:09 UTC 2022
> > >> 
> > >> Modified Files:
> > >>    pkgsrc/pkgtools/osabi: INSTALL
> > >> 
> > >> Log Message:
> > >> osabi: Teach it to check the version of the userspace rather than
> > >> the kernel on NetBSD. from Hauke Fath.
> > >
> > > This completely defeats the purpose of the package for the
> majority of
> > > the packages using it. While it is important for the native X11
> version
> > > check, its primary use case is fixing the kernel ABI for things
> like
> > > /dev/kmem using tools. That's completely broken now.
> > 
> > If this isn't just reverted, please discuss on tech-pkg; seems like
> > pre-discussion wass (in 20/20 hindsight) warranted as it is
> > controversial.
> > 
> > Adding a second package that is os-userland-abi seems fine; it seems
> > clear there are at least two issues
> 
> Reverted.

Hi Nia,

Right now, osabi is broken for any NetBSD system where kernel and
userland don't match versions, as OS_VERSION is still determined the
"new" way in bsd.prefs.mk while osabi's INSTALL was reverted to the
"old" way, so it will refuse to install (unless someone's specifically
disabled that via CHECK_OSABI, which I don't do in some contexts).

Both OS_VERSION and OPSYS_VERSION presently seem to mix meanings of
whether they're intended to detect a kernel or userland feature,
depending on the package in question (and some I'm not quite sure which
-- or even both -- it's meant to detect). I don't feel changing either
existing variable to detect userland instead is an improvement, just a
different kind of potential confusion or breakage.

The change to OS_VERSION also had unexpected effects for one of my bulk
build setups, as it was bootstrapped with 9.99.42 and still had those
details in its (chrooted) etc/release, despite the kernel and userland
both being 9.99.99 (since /etc/release never had any influence before,
I'd never thought to update it). osabi was failing to build and so some
of the packages (e.g., some MATE packages depend on libgtop). If this
were the only issue, I'd hardly object, except, I think then it still
should have been a "flag day" kind of change.

Could we please completely revert this and then discuss how we want to
separate the two meanings? Greg has already suggested a distinct
package for userland detection (with differently named variables),
which sounds good to me.

Regards,

Dave