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