Bug 10940 - lib64ncursesw5, lib64ncurses5 should contain libtinfo.so.5 (not sure about a "w" version)
Summary: lib64ncursesw5, lib64ncurses5 should contain libtinfo.so.5 (not sure about a ...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 3
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords: Triaged
Depends on:
Blocks:
 
Reported: 2013-08-06 22:39 CEST by Rick Stockton
Modified: 2014-02-23 19:08 CET (History)
5 users (show)

See Also:
Source RPM: ncurses
CVE:
Status comment:

Attachments
Patch to add libtic and disable/obsolete termcap/libterrmcap (2.34 KB, text/plain)
2013-08-07 15:53 CEST, Colin Guthrie 		Details
Proper patch (3.25 KB, text/plain)
2013-08-07 16:05 CEST, Colin Guthrie 		Details
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Description Rick Stockton 2013-08-06 22:39:03 CEST 
In OpenSuse, Fedora, and CentOS, packages "ncurses-libs-5.x.y" provide "libtic.so.5" and "libtinfo.so.5".

Our similar packages (e.g., lib64ncurses5) provide:
   /lib64/libform.so.5
   /usr/lib64/libform.so.5.9
   /usr/lib64/libmenu.so.5
   /usr/lib64/libmenu.so.5.9
   /usr/lib64/libncurses.so.5
   â/usr/lib64/libncurses.so.5.9
   /usr/lib64/libpanel.so.5
   /usr/lib64/libpanel.so.5.9

but they lack corresponding:
   /usr/lib64/libtic.so.5
   /usr/lib64/libtinfo.so.5

3rd party packages built for RPM distros (e.g., Vista EHR) are linked to libtinfo.so.5

I wonder, why did we choose to ship without it? And why not include it, instead of creatng custom builds for some other things which generally link this library? (e.g. NVIDIA CUDA Toolkit 5.0.35)
Manuel Hiebel 2013-08-06 22:49:37 CEST

Keywords: (none) => Triaged
CC: (none) => dirteat, fundawang, mageia, mageia, thierry.vignaud
Source RPM: (none) => ncurses

Comment 1 Colin Guthrie 2013-08-07 10:13:12 CEST 
I have a local build here that builds fine with tinfo, so incorporating that change should be fine.

Regarding libtic, it requires passing --enable-ticlib to configure, but that also requires not passing --enable-termcap.

Ultimately the fedora ncurses package seems to obsolete termcap and provide a termcap-devel compatibility layer (basically linking to tinfo it seems).

I'm not sure of the implications of this, but if others are happy to push ahead with this change I can commit what I have and do the necessary fixups to obsolete libtermcap and provide it here.
Comment 2 Colin Guthrie 2013-08-07 10:17:28 CEST 
A quick google/wikipedia suggests this should generally be OK. termcap was dropped from fedora 6 years ago so I suspect bar a few conversion issues, we should be OK :)
Comment 3 Colin Guthrie 2013-08-07 15:53:13 CEST 
Created attachment 4249 [details]
Patch to add libtic and disable/obsolete termcap/libterrmcap

OK, I committed some spec tidyups etc.

Attached is a patch which obsoletes termcap/libtermcap and adds a compatibility .so file to (hopefully) make the transition silent.

I installed the resulting RPM, and recompiled bash and it now links against libtinfo.

I didn't test it, but if others think this is the right approach we should do it before the mass rebuild.
Comment 4 Colin Guthrie 2013-08-07 16:05:15 CEST 
Created attachment 4250 [details]
Proper patch

Ignore the last one, this one is the correct one.

Attachment 4249 is obsolete: 0 => 1

Comment 5 Chris Denice 2013-08-07 17:37:09 CEST 
Hi there,
tested various terminals with Colin's patched spec rpm, Eterm, aterm, xterm, rxvt-unicode, they work fine. So, for me you can push, but others may want to test other parts.

Thanks!

chris.
Comment 6 Colin Guthrie 2014-02-23 19:08:06 CET 
This was resolved a while back.

Status: NEW => RESOLVED
Resolution: (none) => FIXED
Note You need to log in before you can comment on or make changes to this bug.