On 2018-02-25 00:55 +0100, Manuel A. Fernandez Montecelo wrote:
> 2018-02-24 8:54 GMT+01:00 Sven Joachim <svenj...@gmx.de>:
>>
>> So here is a possible plan:
>>
>> - Do *not* fix this bug in unstable now, to exclude the possibility of
>> the above symbol lookup error after a cwidget rebuild when the ncurses
>> transition starts.
>>
>> - After ncurses has been accepted in experimental, upload cwidget there
>> too. Rename the library package again, say to libcwidget3v6, and
>> build-depend on libncurses-dev (>= 6.0+20180210) to ensure that it gets
>> linked against libncursesw6 rather than libncursesw5.
>>
>> - When the ncurses transition starts in unstable, both aptitude and
>> cwidget still FTBFS. Upload the new cwidget package to unstable, get
>> aptitude binNMU'ed, and everyone is happy.
>>
>> Does this sound reasonable?
>
> Yes, with the following comments/caveats (mostly reminders for myself,
> or somebody else if ends up doing this):
>
> - the "v5" suffix was for the GCC5 transition (changes due to C++11
> ABI), the name should be "libcwidget4" or something. I wanted to
> change a couple of minor things and bump the soversion anyway, just
> never find the time to sort out all of the details, so let's see :)
I guess libcwidget4 should only be chosen as package name if you bump
the soname to 4, which of course would be very welcome by me.
> Thanks for the detailed follow-up and taking care of these details :)
This evening I had a closer look at all the mmask_t users in Debian, and
indeed cwidget seems to be the only package which uses it as a parameter
in a public library function. So I'll stick to the new upstream default
type for it.
Meanwhile, ncurses 6.1+20180210-1 is sitting in NEW awaiting review by
the FTP masters.
Cheers,
Sven
