> > 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. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
