David Engel writes ("Re: ncurses-1.9.8a ELF release"):
> [ and earlier: ]
> > > The runtime package installs the shared libraries as lib*.so.3.0.new
> > > and then renames them to lib*.so.3.0 in the postinst script. This is
> > > fine for not disturbing running programs when the package is being
> > > upgraded, but there is no provision for deleting the files when the
> > > package is removed. Again, I'd like to hear Ian Jackson's thoughts on
> > > adding special installation support for shared libraries to dpkg.
>
> Ian Jackson, are you there? I'd *really* like to hear your opinions
> on this.
Yes, I'm here. Sorry, I haven't been reading this mail for a few days
and I'm noow catching up on a 400-message backlog.
As far as I can see we have three kinds of shared library:
1. Packages like X or mkfs or what have you, where it doesn't matter
if the library link is missing momentarily, or even if it's absent
while the package is in a "broken" state according to dpkg.
2. Packages like the libc or ncurses, where we can't leave it broken
even for an instant without risking an unrecoverable system.
3. The shared library is part of the same package as the executables
and is version-specific - it's just there to save disk space and
memory, and furthermore this is a critical package which we can't
leave broken.
AFAIK only dpkg falls into category 3. Lots of things fall into
category 1, but they can do without special handling.
Category 1 needs the link to be updated *with both libraries present*,
am I right ?
If you naively install the libraries under their real names in the
package, then there will only be a brief period while dpkg is running
when both libraries are present, and there's not currently any way to
get a script or anything run there.
You could possibly fudge something up with the maintainer scripts, and
putting the files in the package under different names.
Could you take a good look at maintainer-script-args.txt in
project/standards, and consider what extra functionality you'd like me
to include in dpkg ?
One possibility is an extra maintainer script called in the guts of
dpkg's processing - if you like that idea, remember to think about
error handling ...
Ian.
