Re: ncurses-1.9.8a ELF release
> > 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?
>
> "Claims to own"? Do you mean "claims to need" ?
No! By "own", I mean that the file belongs to a package and shows
up when running "dpkg -L" on that package. I'm assuming that dpkg's
normal dependency checking won't allow the package to be removed while
others still depend on/need it.
> And is "foo-n" the package name, or is "foo" the package name and "n"
> the version ?
Foo and bar are package names. N, m and p are different versions
and/or revisions.
> Sorry, I'm still confused.
>
> What I meant was that, supposing you upgrade libc5 from 5.0.9-1 to
> 5.2.7-1, you find that the old package contains libc.so.5.0.9 and the
> new libc.so.5.2.7. The link needs to be changed to point at 5.2.9
> when *both* files are available, surely, as otherwise it will point
> into nowhere for a bit ?
Now I'm confused. That part of my message was in reference to your
comment on category 1 packages where you contradicted yourself. Did
you mean category 2 instead? Here is the relevant section from your
earlier message:
> 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 ?
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: