On Sat, Feb 10, 2018 at 01:57:48PM +0100, Sven Joachim wrote: > On 2016-12-03 17:31 -0500, Thomas Dickey wrote: > > > On Wed, Nov 30, 2016 at 08:54:02PM +0100, Sven Joachim wrote: > >> On 2012-01-22 10:58 +0100, Sven Joachim wrote: > >> > >> Fortunately this has all been done by upstream in the meantime, the > >> ncurses package in Debian uses versioned symbols[1], and all reverse > >> dependencies in testing have been rebuilt[2]. So the long requested > >> soname bump can finally happen after the Stretch release. :-) > >> > >> Before I start working, there are some things which should be decided. > >> > >> - Right now we ship both wide and non-wide versions of the libraries and > >> the -dev packages, with the ncursesw headers shipped in a separate > >> directory. This leads to problems where reverse dependencies use the > >> wrong headers, see [3] for an example, and I want to change it. > >> > >> There are two possibilities here: > >> > >> 1. Install the headers for the wide libraries only, and use them for > >> the non-wide libraries. This is expected to work and is what > >> Fedora has been doing for a long time, but there seem to be a few > >> compatibility problems in the ncurses 6 API[4]. > > > > The problem is that ncurses6 uses extended color information which can't > > fit into chtype's (the basis of non-wide ncurses5). That makes it use > > cchar_t's (which are the basis of wide ncurses5/ncurses6). > > > > The Red Hat bug report points out that the macros which use details of > > the WINDOW structure are a problem which prevents using the headers as-is > > between the three flavors (ncurses5 normal/wide and ncurses6). In a quick > > review of curses.h, those are > > > > wattrset > > wattr_set > > wattr_get > > > > If the macros are not available, the library provides functions for > > each of those macros. The performance impact for using the functions > > rather than the macros may not be that high. > > One week later you added a --disable-wattr-macros configure option which > Fedora uses now, I guess we should do the same.
sure, if it helps. I haven't found it necessary in the configurations that I use for development. > >> - Should we continue to distribute separate debugging libraries? Nobody > >> else does that, apparently. > > Tracked in #849003, I guess we'll have to see if someone complains after > the packages are gone. > > >> - The multilib packages have been a constant source of bugs and are > >> considered unsupportable by the dpkg maintainer[6], I want to get rid > >> of them. Reverse dependencies are grub-legacy and readline whose > >> multilib packages don't have any reverse dependencies themselves. > > Filed #848166 and #848168 for those. > > >> - Should we continue to ship libncurses5 and libncursesw5 packages? As > >> long as upstream supports building them, this might make sense. > > > > I've no intention of breaking the ncurses5 stuff (keeping in mind that > > LSB specifies ABI 5...). > > While Debian no longer supports the LSB, I suspect there are enough > popular proprietary applications out there that use ABI 5 ncurses > libraries, so I guess they should be kept for now. For the time being, I'm still test-compiling ABI 5, but aside from verifying compatibility, all of my work's on ABI 6. -- Thomas E. Dickey <dic...@invisible-island.net> https://invisible-island.net ftp://ftp.invisible-island.net
signature.asc
Description: Digital signature
