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

Re: New ncurses packages...



On Fri, 19 Jan 1996, Michael Alan Dorman wrote:

> I've modified the control files for these so that ncurses-base now
> provides ncurses-runtime.
> 
> As I understand it, this should allow dselect and/or dpkg to DTRT when
> upgrading from the a.out ncurses-runtime.  Any firsthand experiences
> would be nice---I haven't had a virgin system to test on in a long
> while.

> Date: 20 Jan 96 00:46 UT
> Source: ncurses
> Binary: ncurses-base ncurses-bin ncurses-term ncurses3.0 ncurses3.0-dev
> Version: 1.9.8a-4

I can't comment on a.out systems.  But I will repeat the observations I 
made on 1.9.8a-3 one month ago and encounter now again: 

root@ernie:tty1:/fs7/debian/binary/base# ldd /bin/sh
        libncurses.so.3.0 => /lib/libncurses.so.3.0
        libc.so.5 => /lib/libc.so.5.2.18
root@ernie:tty1:/fs7/debian/binary/base# dpkg -i ncurses3.0-1.9.8a-4.deb
(Reading database ... 7713 files and directories currently installed.)
Preparing to replace ncurses3.0 (using ncurses3.0-1.9.8a-4.deb) ...
Unpacking replacement ncurses3.0 ...
Setting up ncurses3.0 ...
sh: can't load library 'libncurses.so.3.0'
dpkg: error processing ncurses3.0 (--install):
 subprocess post-installation script returned error exit status 16
Errors were encountered while processing:
 ncurses3.0
root@ernie:tty1:/fs7/debian/binary/base# mv /lib/libncurses.so.3.0.new /lib/libncurses.so.3.0

Note:
The *.deb files are created from source by me.  I expect they are almost
identical to these from Michael.  The problem above will happen *only* 
because the way my bash is linked -- but I predict this on debian systems 
for the future.

A solution during the installation process may be:
  - copy the old shared object into an other directory, e.g. /baz
  - export LD_LIBRARY_PATH=/baz
  - install new shared object
  - remove copy in /baz

I think there should be a template for installing/upgrading shared libs to
avoid the duplicate experiments for lib{c,ncurses,db,gdbm,readline,...}.

Somewhat related, I want to remember the debian package maintainer
to my memo 'Useless use of "-lfoo"' again, which explains how an innocent
binary could turn into a similar showstopper.

mfg
Rolf Rossius


Reply to: