On 29.08.2019 13:55, Roy Marples wrote: > On 29/08/2019 03:45, Thor Lancelot Simon wrote: >> On Wed, Aug 28, 2019 at 10:42:13PM -0400, Thor Lancelot Simon wrote: >>> On Wed, Aug 28, 2019 at 01:54:54AM +0100, Roy Marples wrote: >>>>>>> >>>>>>> Where 8.2 is taken from the .so version? >>>>>>> >>>>>>> Roy >>>>> >>>>> I think that it would be confused with NetBSD release and it could be >>>>> meaningless/confusing for downstream users that just pick the code >>>>> as is >>>>> and can pick different major/minor. >>>> >>>> Then I'm against this being added because it adds nothing of value. >>>> >>>> I note that PD curses also supports curses_version() with something >>>> similar >>>> to my proposal. >>> >>> The problem with using the solib version is that it may differ on >>> platforms derived from NetBSD even if the curses API is exactly the >>> same. >>> >>> This would, for example, have been the case on EQ/OS which I maintained >>> at Coyote Point - we bumped all the shlib versions at least once because >>> of a change to libc. >> >> Sorry, hit send a little early and left out the ugliest detail. >> >> The problem then really is that if, let's say, my EQ/OS libcurses had >> reported 9.2 for a libcurses that was called 8.2 in NetBSD, when NetBSD >> bumps its libcurses to 8.2 for real API-change reasons within libcurses, >> my version will look like it has the API change but actually it won't. >> >> You really don't want to use the solib version for this sort of thing >> because it will not mean the same thing on different platforms for the >> exact same version of the code implementing the API, because it must be >> bumped every time the library's *ABI* changes -- and that must be done >> every time some library upon which _it_ depends changes, in turn. >> >> A version like __NetBSD_Version should be used. > > Attached is a patch which adds __NetBSD_Curses_Version__ to curses.h in > the same manner as __NetBSD_Version__ from sys/param.h. > Should we document __NetBSD_Curses_Version__ in the curses_version.3 man > page? > > version.h is generated using a variant of osrelease.sh to extract the > version numbers from that. > version.c includes this file and make up a string: > "NetBSD-Curses " CURSES_VERSION " - " __DATE__; > > output: > NetBSD-Curses 1.0.0 - Aug 29 2019 > > I'm unsure if we need the date there or not - Kamil seems to think it's > a good idea and it's also done like so in PDCurses. But would this > affect our reproducable builds? > > Roy __DATE__ breaks MKREPRO. In my opinion artificial versioning (1.0.0) of native code adds no interesting information and adds burden on us for superfluous versioning model, orthogonal to __NetBSD_Version__. As I have grepped the projects (in Debian code search), likely nothing depends on the version string from this function, it's just a utility to represent self. I think we try to solve here a problem that does not exist. SVR4 curses returns "curses (SVR4)" (as an implementation difference, they defined it as char*, not as a function). Adding extra versioning would make sense if we could maintain curses(3) out of the NetBSD context.
Attachment:
signature.asc
Description: OpenPGP digital signature