[re-sent to list] pkgsrcOn 7/22/22 12:19 PM, Robert Elz wrote:
Date: Fri, 22 Jul 2022 10:02:48 +0200
From: Hauke Fath <hf%spg.tu-darmstadt.de@localhost>
Message-ID: <20220722100248112297.35703c73%spg.tu-darmstadt.de@localhost>
| Well, provided the (newer) kernel has backward compatibility, what
| determines the "system version" is really the system headers and
| libraries, not the kernel API. So one might want to look at
| /etc/release, instead of uname output...
That is all very true ... but /etc/release is kind of local,
... and in this case a good solution to a local problem. Thanks, Nia, for running with it!
and is a 150 line monstrosity (nice to have, but still). The first of those lines is all that is needed for this purpose, but the build system still needs alternative methods for all those systems where this doesn't work. Something better, and more widely implemented, is needed.
The problem at hand - a skew between what uname(1) reports, the kernel version, and what actually matters to package builds, the userland interfaces - is probably a *BSD, maybe even a uniquely NetBSD problem. How many other systems will support enough backward compatibility to show such skew in a regular setup?
Of course, the best (and therefor most costly) method is not to rely upon some all knowing single version number, but to explicitly test (or when necessary, ask) for all functionality that cannot simply be assumed to exist in a known form.
That's what build systems, from the venerable autohell to newfangled python based systems have been trying to do for a long time. In the case at hand, clang's cmake blackbox could have checked for interface capabilities, and went with the OS version instead.
Cheerio,
Hauke
--
The ASCII Ribbon Campaign Hauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
Respect for open standards Ruf +49-6151-16-21344