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.
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.
Reply to: