Bugzilla Bug 103105

tracker bug to get libtermcap-compat out of portage

package maintainers, please fix up your packages (listed below) to remove
libtermcap usage


app-admin/apachetop: web-apps

app-editors/gvim: vim
app-editors/vim-core: vim
app-editors/vim: vim

app-editors/zile: emacs

app-misc/aldo: no one

app-office/mdbtools: no one

dev-db/libodbc++: robbat2

dev-util/mono-debugger: dotnet

dev-util/fenris: liquidx

mail-client/hap: net-mail

net-p2p/hx: net-p2p / kang

sci-chemistry/nrmrpipe: ribosome

sci-electronics/magic: sci
sci-mathematics/octave-forge: sci

What's the replacement, or workaround?

I've just removed mono-debugger from the tree. This package has been p.masked
for a while, and was pending removal anyway. Removing dotnet CC.

Another question: Why do you want to remove this package? I suppose fixing all  
packages not to depend on it would require quite some work, so I assume there  
is a compelling reason to remove libtermcap from the tree.  

Anyway, NMRPipe is distributed only in binary form, so there is no way it will  
get fixed, and I certainly will not remove it from the tree or cripple it. 

the replacement is to use ncurses

the current libtermcap-compat package installs the runtime library
(libtermcap.so.2) but it will not allow you to build/link against it since it
does install the header files or libtermcap.so

i'll worry about binary-only packages later ... for now, fix the source packages

mail-client/hap-3.7-r1 is in CVS (~arched) and it doesn't depend upon
libtermcap-compat anymore.

Cheers,
Ferdy

sci-electronics/magic done (-r5 in ~arch)

vim-6.3.086 no longer offers termcap as an option.

"sci-mathematics/octave-forge" fixed (in ~arch). Work done for the sci herd.  

NMRPipe will not work with ncurses. However, the binary package bundles its  
own libtermcap-compat library, which the ebuild deletes in favor of the Gentoo 
one. I could use that bundled library if you absolutely want to get rid of 
"sys-libs/libtermcap-compat". 

i know NMRPipe wont work with ncurses since it's a binary-only package

if we can get all of our source packages moved over to ncurses, then i'd be ok
with libtermcap-compat just installing the file needed for apps to run (namely,
libtermcap.so.#)

apachetop seems to be all set

>=net-p2p/hx-0.4.11 is fixed (~arch)

libtermcap-compat-2.0.8-r2 should be masked because it doesn't emerge:

mv: cannot move `lib' to a subdirectory of itself, `lib/lib'

!!! ERROR: sys-libs/libtermcap-compat-2.0.8-r2 failed.
Call stack:
  ebuild.sh, line 1546:   Called dyn_install
  ebuild.sh, line 1020:   Called src_install
  libtermcap-compat-2.0.8-r2.ebuild, line 59:   Called die

!!! (no error message)
!!! If you need support, post the topmost build error, and the call stack if
relevant.

(1) that isnt how masking works
(2) your report is unrelated to this one; you should have filed a new bug
report
(3) ive fixed the issue in cvs

robbat2, can you take a look at the following proposed libodbc++ update and see
if you approve

Created an attachment (id=98408) [edit]
update libodbc++ to build against ncurses

I suggest a rev bump here because I think isql++ was unintentionally disabled
by configure if the system's readline needed ncurses instead of termcap

libodbc++ fixed now.
amd64 needs to stablize 0.2.3-r2 to enable this removal to continue.

@net-mail: ok to stabilize mail-client/hap-3.7-r1 now?

app-editors/zile does not depend on libtermcap-compat anymore

mysql-gui-tools-5.0_p10-r1.ebuild should also be fixed, because it tries to
link libtermcap in the following Makefile:

archive mysql-gui-tools-5.0r10.tar.gz:
mysql-gui-common/tools/grtsh/Makefile.am

What's left?

dev-util/fenris-0.07m-r2 (no maintainer ATM, doesn't compile anyway - Bug
46620)
mail-client/hap-3.7 (-r1 stabilization - Bug 173771)
sci-chemistry/nmrpipe-2.5.2006.184.15.37 
sci-mathematics/octave-forge-2004.11.16-r1
sci-mathematics/octave-forge-2005.06.13
sci-mathematics/octave-forge-2006.01.28
sci-mathematics/octave-forge-2006.03.17

I've just fixed all of sci-mathematics/octave-forge*

Best,
Markus

the state of the tree is now that we can move on -- libtermcap-compat only
provides the SONAME library needed for binary packages