Re: Add curses_version() in curses(3)

2019-09-02 Thread Brett Lymn
On Mon, Sep 02, 2019 at 03:32:36PM +0200, Kamil Rytarowski wrote:
> 
> I'm for a static string like "NetBSD Curses"/"NetBSD-Curses" or even
> "NetBSD" (comparable to "SVR4" in SVR4 Curses"), but Roy insisted on a
> numerical version.
> 

I haven't read down thread yet but Roy has just implemented something
that sort of matches the ncurses version which returns the name, a major
version and some date string.

> netbsd-curses a downstream fork uses its own versioning model and we do
> not need to bother with any numbers locally.
> 

Sadly, matching the somewhat egregious behaviours of ncurses does
result in fewer PRs of the ilk "it works this way in ncurses..."

-- 
Brett Lymn
--
Sent from my NetBSD device.

"We are were wolves",
"You mean werewolves?",
"No we were wolves, now we are something else entirely",
"Oh"


Re: Add curses_version() in curses(3)

2019-09-02 Thread Kamil Rytarowski
On 02.09.2019 15:11, Valery Ushakov wrote:
> On Mon, Sep 02, 2019 at 12:32:51 +0300, Valery Ushakov wrote:
> 
>> Why would we ever want to report this completely random and unrelated
>> fact?!
>>
>> There were years when curses in the tree was unchanged.  In the mean
>> time we have churned through dozens of netbsd versions.
>>
>> Why are we trying to over-engineer this?
> 
> So the original claim was that it's needed by qemu.

For the reference. I noted that I originally needed it, not that I still
need it in qemu. I have patched upstream qemu to stop using it.

https://github.com/qemu/qemu/commit/271f37abb510607ca7650e40951284692a67579a

Although there are qemu forks in the wild; some of them still need it
(at least hqemu is interesting to me).

>  I've downloaded
> qemu-3.1.1, qemu-4.1.0, and qemu.git and I don't see it mentioned
> anywhere, grep -r curses_version qemu* returns nothing.
> 
> I've searched github and I see manual pages to curses_version in
> various formats, binding for curses_version for various scripting
> languages.  configure tests that seems to check the presense of
> curses_version to detect ncurses.
> 
> NB: have we just broken all those configure scripts?
> 
> I don't see this function actually being used for anything though I
> haven't clicked through all the 31K occurrences.
> 
> I cannot really conceive how this function can be useful for anything
> other that printing that information as part of some banner.  A
> program that makes some kind of decision about how to use curses by
> inspecting this value at runtime?  I'd sooner belive in unicorns :)
> 
> My preference would be to either revert this and pretend it never
> happened or to make it return a static string "All your base are
> belong to us" b/c we really don't have any meaningful versioning for
> our curses and pretending otherwise by returning completely unrelated
> netbsd version just makes us look stupid, IMO.  (As Christoph noted,
> do we now have to bump netbsd version if we make a change in curses?
> :)
> 
> I'm sorry I should have joined this bikeshed earlier, but as I said I
> didn't realize what was actually going to be committed.  I'm sorry I
> let Roy to be mobbed into this.
> 
> -uwe
> 

I'm for a static string like "NetBSD Curses"/"NetBSD-Curses" or even
"NetBSD" (comparable to "SVR4" in SVR4 Curses"), but Roy insisted on a
numerical version.

netbsd-curses a downstream fork uses its own versioning model and we do
not need to bother with any numbers locally.

The current approach is a consensus in that matter.



signature.asc
Description: OpenPGP digital signature


Re: Add curses_version() in curses(3)

2019-09-02 Thread Valery Ushakov
[copying here my reply from source-changes-d]

On Fri, Aug 30, 2019 at 18:22:37 +0100, Roy Marples wrote:

> On 30/08/2019 18:09, Kamil Rytarowski wrote:
> > On 30.08.2019 18:55, Roy Marples wrote:
> > > return "NetBSD-Curses " CURSES_VERSION
> > 
> > I propose to go for:
> > 
> > return "NetBSD-" CURSES_VERSION " Curses";
> > 
> > With removed __DATE__ that is not MKREPRO friendly.
> > 
> > The rest looks fine.
> 
> I dislike having the version in the middle - convention has it at the end.
> I'd go with
> 
> return "NetBSD-Curses " CURSES_VERSION
> 
> or
> 
> return "NetBSD " CURSES_VERSION

I know I'm late, but I kept quiet as this was kinda misleading as it
used CURSES_VERSION in version.c and I didn't realize it was actually
the netbsd version from osrelease.sh.  Committed code calls it
NETBSD_VERSION, which made me pay attention.

Why would we ever want to report this completely random and unrelated
fact?!

There were years when curses in the tree was unchanged.  In the mean
time we have churned through dozens of netbsd versions.

Why are we trying to over-engineer this?

-uwe