Re: Can version bump up to 9.99.100?

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

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" <david%gutteridge.ca@localhost>
>     Message-ID:  <de10cc9a2340b5cb6f99e1c3f219d6f5%gutteridge.ca@localhost>
> 
>   | 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