Re: curses/termcap (was gdbm vs db)
> I propose:
>
> - We make a package out of ncurses 1.9.8a, with the appropriate
> definitions for linux (--prefix=/usr, linux console terminfo compiled
> in as fallback, etc etc).
OK so far.
> - We use the soname "libcurses.so.2" (or .5, if we want it consistent
> with libc versions). We leave the `ncurses' soname alone for people
> who want to build their own ncurses from vanilla sources.
I don't see what's wrong with using libncurses.so.3.0. We are using
it for Debian and haven't had any problems.
> - We don't change it except to fix bugs, and we recommend distribution
> makers to include it as `the system curses library'. If they want to
> add support for a later ncurses version, they can put it in
> /usr/include/ncurses, and use "libncurses"-based sonames.
Who are you going to get to maintain it and fix the bugs?
> Also, I haven't yet looked at H J's new termcap library, but what's it
> for? Is it supposed to be used generally for applications that only
> need termcap support, or specifically for programs that want to go on
> a rescue disk (or otherwise be very small). I hope the latter, and
The problem with using termcap is that some programs will use
/etc/termcap and others will use /usr/lib/terminfo. I'd rather see
effort put into fixing the termcap emulation bugs in ncurses rather
than into maintaining and perpetuating termcap.
> given that, I hope that it installs itself and its header files
> somewhere other than /usr/lib/ and /usr/include/. Ultimately, it's
> not compatible with terminfo-based curses, and if it's put in standard
> places I can see people getting burned by mixing & matching header
> files, or by attempting to link with curses and termcap. Remember,
> emacs used to break this way (actually, still does).
>
> We do want to use terminfo curses as the primary curses
> implementation, right?
Definitely.
> Oh, and if I get any positive feedback (especially from people
> responsible for distributions) about the soname, I will go ahead and
Debian already *has* standardized on ncurses. Of course, if Zeyd or
whomever starts changing the ABI willy nilly without concern for
backwards compatibility, we will probably consider maintaining our own
version.
> build this thing (against libc 5.2.18), and put it up on
> ftp.linux.org.uk. For the benefit of everyone who distributes
> binaries or who uses those distributed binaries, WE NEED A _STANDARD_
> CURSES library. Not a set of marginally-incompatible ones with
> major versions that include 1, 1.9, 2.0 and 2.1. Rant over. It'd be
> nice to get this fixed before the next big XFree86 release, before the
> next Emacs release (which won't build against ncurses 1.9.7) and
> before the 2.0 kernel comes out.
>
> Comments?
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: