> > > 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.
Ah, right. In that case, the answer is that dpkg does this already - but it does it (removes the old libfoo.x.y) before th the postinst runs. Plain files are oonly in one package at once. > > 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: Yes, I did mean categoory 2 instead. Is this getting any clearer ? :-/ Ian.