Re: Proposed change to dpkg behaviour
Chris Fearnley writes ("Re: Proposed change to dpkg behaviour"):
> Probably this is the right way to do it. BUT, for me the bigger
> problem I was hoping could be solved by a Replaces: field is upgrading
I think David Engel and I have figured out what to do about shared
> For libraries there is the difficulty of other packages
> depending on them. But the newer version of a package may not be
> backward-compatible and the older version may still be needed for stuff
> the local sysadmin compiles herself.
So, the two shared library packages have different package names, and
you can install or remove them separately. The user won't be able to
remove the old shared libraries until all the stuff that depends on
them is gone.
(In private email Chris resent to me a message from January, where he
suggested that the old library package be removed once the
dependencies are OK.)
I'm not going to arrange for libraries to disappear automatically,
because the user might have compiled or installed other software that
depends on them. Requiring the user to know about this and not select
the package for removal is one thing; having the user have to do some
magic something to stop the library being removed is quite another !
> In these cases something like the
> conffiles mechanism might be useful.