On 06/25/2011 06:34 PM, Sven Joachim wrote: > tags 631592 + help > thanks > > On 2011-06-25 09:37 +0200, Matthias Klose wrote: > >> Package: ncurses >> Version: 5.9-1 >> Severity: important >> >> ncurses should be configured with --with-termlib so that packages which do >> not >> rely on the symbols exported by ncurses/ncursesw, but only on symbols found >> in >> libtermlib. > > I concur that this is desirable, but it breaks the ABI. If we were to do > that, we could probably drop the non-wide development packages altogether. > There are some obstacles to an ABI break, because ncurses > > - does not provide versioned symbols > > - exports many (all?) internal symbols (those starting with _nc_) > > - exposes many of these symbols in the public headers: > $ grep _nc_ /usr/include/ncursesw/*.h | wc -l > 155 > > Considering how many libraries in Debian are linked against libncurses5 > and that we have to retain libncurses5 for a very long time per LSB > compatibility and users' demand, I don't really have an idea how to > proceed.
please can we first build libncursesw this way, and provide a new package providing the new shared libraries? $ grep-dctrl -FBuild-Depends -s Package libncurses5-dev /var/lib/apt/lists/*_source_Sources |wc -l 437 $ grep-dctrl -FBuild-Depends -s Package libncursesw5-dev /var/lib/apt/lists/*_source_Sources |wc -l 89 this looks easier than attacking the non-wide case. what follows ... your choice, but this would allow us to have some progress, and it should not matter, if the symbols come from the libncurses5 library or one of the new shared libraries. would it be possible to check the build logs of the package b-d on libncursesw5-dev, that these really have the appropriate -I option in the compiler flags? Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
