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

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 Engel                        Optical Data Systems, Inc.
david@ods.com                      1101 E. Arapaho Road
(214) 234-6400                     Richardson, TX  75081

Reply to: