Re: ncurses build options...
> > > If the ncurses guys are going to keep blowing off binary compatibility,
> > > then perhaps we should not mess with ncurses at all.
> > I suspect, especially now that we've got the package load spread around
> > more, that Debian will be able to keep up.
> I'm just concerned that this is a losing battle. It might be fine for
> static libraries, but for shared libraries to be effective they need to
> remain compatible from one version to the next.
> This is going to be a big problem for Linux binary compatibility between
Seems that dpkg should presently be able to handle this, as far as
package installation goes, via the dependency mechanism, presuming
that the distribution includes all the version-numbered ncurses
libraries which are still package dependency targets, and packages
are careful about declaring dependencies on them. (Hmmmm.. MSDOS
filenaming for the multiple ncurses libs will need to include
It seems to me that the the sequence would go something like this:
1. User initially installs debain-x.y-z, including one or more essential
version numbered ncurses libs, and packages depending on various
of these libs.
2. Package upgrades remove dependencies on some of these installed
ncurses libs, as packages migrate to newer versions. User probably
uses naked dpkg to install upgrades, because dselect [I]nstall is
very slow when installing individual packages.
3. User somehow (how?) becomes aware that some of his installed ncurses
libs have become free of dependencies.
4. User says something like "dpkg --remove --force-essential list_of_libs".
Libraries in list_of_libs which are free of dependencies are removed.
Libraries in list_of_libs which are not free of dependencies are
not removed. I don't really like the idea of users needing to
use dpkg --force-things routinely, though. Perhaps this should
be front-ended through dselect. There might be a new section
for essential libs, and dselect could try to remove any of those
which are free of dependencies during periodic user system
Note that there's at least one tool, cfengine, which can be used
to automate housekeeping such as this. I've seen another tool,
Linuxconf, recently announced in c.o.l-announce which might be used
as well. If housekeeping like this is done periodically, it might
remove the need for the user to become aware of ncurses libs which
have become dependency-free.