Installing coreutils (unstable), it pulls in libtermcap-compat (should be terminfo). Termcap has been declared obsolete a very long time (>8 years) ago, in fact, other distributions only provide a libc5 version to enable REALLY ancient binaries to run and explicitely state new packages must NOT link to it. On top of that, libtermcap-compat installs libtermcap.so in /lib (versionless symlinks to libraries in /lib still belong in /usr/lib), causing coreutils progs linking to libtermcap.a. (now coreutils' binaries in /bin sum up to >2.6MB. Is bug #36453 completely being ignored?)
MArtin, no, the other bug is NOT being ignored, but as Azarah stated, if you can get us a list of files which can be moved into /usr/bin without breaking gentoo's init then I'll implement that soonest. Please note: I'm relying on YOUR input for this, because I haven't the time to test every combination.
now, as for terminfo/termcap -- they are both from the same HOMEPAGE (Eric S. Raymond's) which provides the /etc/termcap file. The termcap compatibility lib is in use by several distros -- Debian, Mandrake at least. If you can find me a replacement, I'll look into it. As for the specific issue of the libs, etc I'm fine with replacing it, after you get me a list of coreutils things which can be moved into /usr/bin.
Martin, come to irc.freenode.net #gentoo and talk to me (I'm seemant there)
OK, so here's what the situation is. I've got in my local overlay, ls, dir and vdir linking to -lcurses instead of -ltermcap and things seem to be well. So I can adjust the patch to do that instead. However, we still require the terminfo/termcap database, so the libtermcap-compat dependency stands. I can, however, consider making a separate package just for termcap without the compatibility lib. But, I'll need Azarah's advice on this.
I'm not a programmer, but here's how I understand it: *termcap* (accessed per libtermcap) and *terminfo* (accessed per ncurses) are two almost compatible ways to do the same thing, only that (a) *termcap* is a bit outdated, (b) *terminfo* is more universal and expressive, ((c) doesn't mean much, but SCO supposedly claims ownership on the termcap file format) In any way, if ls is linked to -lcurses, it'll use terminfo, not termcap. If the dependancy is introduced by Mandrake patches, Mandrake does lots of wierd unexplained things. Here's what Debian has to say since the dawn of time (I have emailed someone who might have the very first Debian version in his collection to see if they never used it and/or when the switch was made. First changelog entry is May 10, 1996): [quote="termcap-compat-1.2.3/debian/control"] Source: termcap-compat Build-Depends: altgcc, libc5-altdev Maintainer: Christian Hudon <chrish@debian.org> Standards-Version: 3.1.1.1 Section: oldlibs Priority: extra Package: termcap-compat Architecture: i386 Depends: ${shlibs:Depends} Replaces: libtermcap Conflicts: libtermcap Description: Compatibility package for old termcap-based programs. The termcap-compat package provides the libtermcap.so.2 and /etc/termcap files which are required to run non-Debian, binary-only termcap-based programs. Since libc6-based programs are hopefully "modern" enough to be linked with ncurses (or slang), this package only provides a libc5-based libtermcap library. . You do not need to install this package to run Debian-packaged programs since Debian GNU/Linux uses terminfo and not termcap. You need this package if a program (that you cannot recompile) fails to run with the error message "...: can't load library 'libtermcap.so.2'" or complains about a missing /etc/termcap file. . The termcap-compat package isn't meant to be used to compile programs therefore it doesn't provide all the necessary files for compilation. If you want to compile a program that claims to need termcap, why not try ncurses's termcap emulation instead? It's as simple as linking with ncurses instead of libtermcap (i.e. replace the '-ltermcap' with '-lncurses' in the makefile). Ncurses' termcap emulation routines translate terminfo entries to termcap entries on the fly, so you don't even need an /etc/termcap file. . This package provides: libtermcap.so shared library, version 2.0.8 termcap database, version 10.2.7 [/quote] --
Sorry for the two dupes (#37064 & #37065). I have no idea how that happened, just responded to #37027.
*** Bug 37064 has been marked as a duplicate of this bug. ***
In theory if we link to ncurses, we do not need /etc/termcap ... except of course if the MDK patches does something wierd with it directly? Comment to termcap - yes it is old, etc. We do however need it for compat like you stated. Most things work if you patch it to -lncurses and not -ltermcap (except a few like app-editors/vi), so we should not need termcap in general. Also, you are right, there needs to be a symlink, but I'd rather use gen_usr_ldscript() in eutils.eclass ..
I don't want to sound selfish, but if a user really wants to use app-editors/vi (there are smaller + more feature-rich vi clones, + they work ok w/ curses), he's not really interested in saving space and won't mind the extra couple of 100Kb /etc/termcap uses. (ironically, on my box app-editors/vi does NOT segfault w/ TERM=linux when it's linked to curses, + w/ curses it works better in xterms - IFF changing "termlib" to "ncurses" is all there is to change (???)) But, that's not the real problem, summary says "coreutils" - coreutils is part of system so it makes termcap part of system. Plus, why does Mandrake's ls need knowledge about its terminal when everyone else does not? --
I think I tried to say that we really should not link coreutils to termcap, but rather ncurses if the need for such support is there. Think you can try to do a patch and test? I do not know if I will get to it until the weekend (Seemant?).
az sorry for late response, I have coreutils -r4 ready to commit (links against ncurses)
-r4 in portage.
Sorry guys, you're forgetting one little thing...ncurses, unlike termcap, stores its terminfo database in `/usr/share'... which may not be available until all file systems are mounted. The other distro that has been mentioned in here solves this by moving entries most probably needed in emergency and rescue situations from `/usr/share/terminfo' to `/etc/terminfo' (don't worry, good news is it's considerably smaller than the whole termcap file... only `dumb', `linux', `rxvt', `screen', `sun', `vt{52,100,102,220}' and `xterm' would go into /etc, rest is still in `/usr/share. Bad news is, since cfdisk (in /sbin) links to ncurses, this would be necessary anyway for 100% correctness, whether `ls' needs ncurses or not). However... it is not really clear why `ls' needs termcap/terminfo... In the unpatched sources, `ls' uses colors with `--color=auto' if stdout is a tty and $TERM matches a term name listed in DIR_COLORS. With the Mandrake patch, coreutils (fileutils) change the first condition as follows, adding the only two refs to termcap/info: /* stdout is a tty */ isatty(STDOUT_FILENO) && /* there's a termcap entry for $TERM */ tgetent(NULL, getenv("TERM")) > 0 && /* the next call queries termcap for the esc sequence used to turn on bold text...or rather checks if the returned *pointer* is > 0 but never uses it for anything... and seems to assume that terminals that can't do bold text can't do colors either and vice versa... (is this always the case?) */ tgetstr("md", NULL) > 0
Stupid question though - I have not checked the ncurses sources yet, but I guess we will have to patch it to also look in /etc/terminfo/ if it cannot open /usr/share/terminfo/ ? Or is it already doing that?
There is a configure option, `--with-terminfo-dirs=XXX' (XXX=colon separated list of directories, e.g. "/etc/terminfo:/usr/share/terminfo")... didn't test yet though if this overrides `~/.terminfo', which should always be searched first.
Ok, have a look at ncurses-5.3-r5 ...
Seemant, you can remove the libtermcap-compat dep if you fixed the linking, also, maybe make it depend on ncurses-5.3-r5?
