Bug#631592: ncurses should provide a termlib library
Matthias Klose
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. Not having a libtermlib would need proliferation of non-wide/wide
library builds for every library depending on ncurses/ncursesw. The first
library needing this is libreadline.
See http://bugs.debian.org/602720 for the initial report and the discussion with
the upstream author. Building libtermlib seems to be the standard way to build
ncurses for other distributions.
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thomas Dickey
> 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. Not having a libtermlib would need proliferation of non-wide/wide
> library builds for every library depending on ncurses/ncursesw. The first
> library needing this is libreadline.
>
> See http://bugs.debian.org/602720 for the initial report and the discussion with
> the upstream author. Building libtermlib seems to be the standard way to build
> ncurses for other distributions.
Clarification:
a) the library itself is normally named "libtinfo".
b) the configure script option is named "--with-termlib".
Some other implementations for instance install symbolic links equating
libtermcap, libterm and libcurses (looking at Solaris). Rather than
use those names, I chose one that didn't conflict with existing usage.
(In retrospect, it might also have been a Good Idea to add a symlink
for libtinfo in the normal --without-termlib build, but again, that
can conflict one way or another...)
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Sven Joachim
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.
> Not having a libtermlib would need proliferation of non-wide/wide
> library builds for every library depending on ncurses/ncursesw. The first
> library needing this is libreadline.
>
> See http://bugs.debian.org/602720 for the initial report and the discussion with
> the upstream author. Building libtermlib seems to be the standard way to build
> ncurses for other distributions.
By "other distributions" you seem to be referring to Fedora, who have
been building ncurses "--with-termlib" since 2007. Opensuse and
Mandriva do not do this, I haven't looked at other distributions yet.
Regards,
Sven
Thomas Dickey
> 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
My point of view here is that versioned symbols are essentially a
Linux-specific feature which for quite a while was at best poorly
documented. When it's been discussed before, I've suggested that people
interested in the feature might send a patch, but recall being told to not
bother - it's their problem, not mine.
>
> - 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
I think the relevant issue here is in ncurses.h (a much smaller number,
which can be dealt with on a case-by-case basis).
> 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.
Perhaps by starting with a proposal for symbol versioning, and applying
that to a package containing only libtinfo.
>> Not having a libtermlib would need proliferation of non-wide/wide
>> library builds for every library depending on ncurses/ncursesw. The first
>> library needing this is libreadline.
>>
>> See http://bugs.debian.org/602720 for the initial report and the discussion with
>> the upstream author. Building libtermlib seems to be the standard way to build
>> ncurses for other distributions.
>
> By "other distributions" you seem to be referring to Fedora, who have
> been building ncurses "--with-termlib" since 2007. Opensuse and
> Mandriva do not do this, I haven't looked at other distributions yet.
Oddly, I've gotten some feedback from Werner Fink for this area,
but agree that I don't see it as their default configuration.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
Matthias Klose
> 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
Matthias Klose
thanks
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.
No, it does not. See the attached patch. The idea is that the new libtinfo5
remains "invisible", by forcing to link with -ltinfo when you link with
-lncurses or -lncursesw.
Matthias
Sven Joachim
Thanks for the patch, but you had better base it on git master rather
than the version in unstable. Could you please adapt it to the
multiarch related changes? Both libtinfo5 and libtinfo5-dev should be
"Multi-Arch: same" then.
Otherwise the patch looks good to me, with only minor nitpicks:
> +Package: libtinfo5-dev
> +Architecture: any
> +Section: libdevel
> +Depends: libtinfo5 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
"Priority: optional" is missing, and there is no need for ${shlibs:Depends}.
> +libtinfo.so.5 #PACKAGE# #MINVER#
> + BC@Base 5.6+20070908
Since the package is new, MINVER can be set to 0 for all symbols.
Thanks,
Matthias Klose
> On 2011-08-25 15:56 +0200, Matthias Klose wrote:
>
>> tag 631592 + patch
>> thanks
>>
>> 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.
>>
>> No, it does not. See the attached patch. The idea is that the new libtinfo5
>> remains "invisible", by forcing to link with -ltinfo when you link with
>> -lncurses or -lncursesw.
>
> Thanks for the patch, but you had better base it on git master rather
> than the version in unstable. Could you please adapt it to the
> multiarch related changes? Both libtinfo5 and libtinfo5-dev should be
> "Multi-Arch: same" then.
well, please merge it. I already spent too much time on this. Given your wrong
claim of breaking the ABI, please go ahead and merge it.
Matthias
Sven Joachim
> On 2011-08-25 15:56 +0200, Matthias Klose wrote:
> Otherwise the patch looks good to me, with only minor nitpicks:
>
>> +Package: libtinfo5-dev
>> +Architecture: any
>> +Section: libdevel
>> +Depends: libtinfo5 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
>
> "Priority: optional" is missing, and there is no need for ${shlibs:Depends}.
I noticed that you added this in the package that you uploaded to
Ubuntu, together with other minor changes. Am I right assuming that I
should use the 5.9-1ubuntu2 package as starting point for the merge?
Regards,
Matthias Klose
> On 2011-08-25 18:02 +0200, Sven Joachim wrote:
>
>> On 2011-08-25 15:56 +0200, Matthias Klose wrote:
>> Otherwise the patch looks good to me, with only minor nitpicks:
>>
>>> +Package: libtinfo5-dev
>>> +Architecture: any
>>> +Section: libdevel
>>> +Depends: libtinfo5 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
>>
>> "Priority: optional" is missing, and there is no need for ${shlibs:Depends}.
>
> I noticed that you added this in the package that you uploaded to
> Ubuntu, together with other minor changes. Am I right assuming that I
> should use the 5.9-1ubuntu2 package as starting point for the merge?
yes, the examples didn't build without an installed version of libtinfo5. Note
that debdiff can't handle symlinks nicely, so maybe it's better to create these
during the package build and remove them on clean again.
Matthias
Sven Joachim
repository, with the following noteworthy differences:
- Dropped the lib64tinfo5-dev package, i.e. merged its contents into
lib64ncurses5-dev. There is no lib64ncursesw5 package and probably
never will be, so we don't need a separate lib64tinfo5-dev package.
- Renamed lib{,32}tinfo5-dev to lib{,32}tinfo-dev following best
practice to not include the soname in -dev package names.
You may need to add some Conflicts/Replaces in the Ubuntu packages to
accommodate that.
Cheers,
Sven