[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> distributions.

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
versioning info).

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
    housekeeping.

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.


Reply to: