Re: ncurses-1.9.8a ELF release
> 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.
OK, I know what that's like.
> 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.
Right. Category 2 is mainly what I'm interested in.
> Category 1 needs the link to be updated *with both libraries present*,
> am I right ?
No, I don't think so. For these, it should be sufficient to just do
it in the postinst script.
> 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 ?
I've been looking at it off and on for the last few days now and I
still don't know if I can do what I want to do. Let me try presenting
the problem differently and you tell me if and how it can be done.
Let's say I have a package named foo-n with a shared library in it
named libfoo.so.x.y that, at least for the time being, must always be
available by that name, even while dpkg is moving things around. Now,
at some point in the future, I know that libfoo.so.x.y whill no longer
be needed for any number of reasons. What I'd like to be able to do
after dpkg is done upgrading foo-n with foo-m, removing foo-n
completely or replacing foo-n with bar-p, is have libfoo.x.y deleted,
if and only if, no remaining package claims to own libfoo.x.y. Can
this be done, and if so, how?
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: