On Sat, 2022-09-17 at 02:50 +0700, Robert Elz wrote: > Date: Fri, 16 Sep 2022 12:59:24 -0400 > From: "David H. Gutteridge" <da...@gutteridge.ca> > Message-ID: <de10cc9a2340b5cb6f99e1c3f219d...@gutteridge.ca> > > | So there will be information loss there, at minimum. Whether that > ends > | up being significant at some point, I guess we can't say. > > I would hope not. That is, I am assuming (but don't know pkgsrc well > enough to be sure) that OPSYS_VERSION gets used for some kind of > feature > test. That's OK (not the ideal method - but sometimes it is the only > practical one) for major, or even minor version comparisons. It isn't > for > the 3rd field (xx) in N.99.xx for NetBSD. That field is not changed > for feature additions, so some N.99.xx may have a particular feature, > and others not, but is changed for internal ABI alterations (which > don't > necessarily affect what is visible by applications in any way at all). > > Note also that this value is never changed (in the NetBSD N.99.xx > case) > because of changes that occur to anything outside the kernel - so it > can > never safely be used to test what version of some application or > library > function might be installed. Never. > > If pkgsrc (or pkgsrc packages) are using this sensibly, then limiting > OPSYS_VERSION at 099999 for all future __NetBSD_Version__ values > 9.99.x > where x >= 100 should be safe, as nothing should ever care about those > final 2 digits. > > That's "if".
Sometimes it's necessary to test for when a feature was added in a -current release, and there's no simple or precise way to do it, as you've noted. If a feature was added sometime in xx.yy.zz, then a test might (retroactively) be expressed with zz+1 as the floor. (An example is some of the ARM compatibility handling in mk/java-vm.mk.) That's not perfect, but it's the reality of pkgsrc. > > kre > > ps: the issue I was concerned about more would occur when the kernel > version info gets embedded in a package version, and other similar > things. Yes, well, there's pkgtools/osabi, for example, which is all about that, and is arguably abused to conflate both kernel and userland (including X11) state at present. This is a bit of a mess in pkgsrc, IMO. It uses a different variable (OS_VERSION), which is expressed as a string output of uname -r, and so shouldn't be impacted here (I haven't checked). Regards, Dave