Hi,
I guess I need to clear up some things here. Let's consider the upgrade
path between between ABI incompatible libraries: The user has A
installed, which depends on libfoo1. libfoo gets changed in an
incompatible way and produces the binary package libfoo2 (in correlation
to the SONAME). Having libfoo provide a libfoo1 dummy package, which
would conflict/replace on the old libfoo1 package would mean, that the
old libfoo1 could get replaced by libfoo1 (dummy) and draw in libfoo2.
However, since libfoo2 is not compatible to libfoo1, A would no longer
work in this state.
Hence it is essential, that two ABI incompatible library versions can be
installed together on the system. (As a result of this, a library
package should not have conffiles due to filename conflicts.)
-> Adding conflicts/replaces would not smooth, but rather break the
upgrade path. An ABI incompatible library does *not* replace the
functionality of the old incompatible version.
Let's see again what would happen if there is no conflicts/replaces:
libfoo1 can not get upgraded, as there is no newer package. a newer A would be
upgraded (A will always need to be rebuilt to pick up libfoo2), depending on
libfoo2, so this package gets drawn in -> libfoo1 and libfoo2 are both
installed. Once no package depends on libfoo1 any longer, libfoo1 is still
installed, but no longer needed. A smart package manager will see that libfoo1
was never directly installed, but only drawn in by A and offer the option to
remove it (that's what apt-get autoremove can do). Problem solved :).
HTH,
Stefan.
--
Request: Upgrade libgdamm3.0 to upstream version 2.9.81
https://bugs.launchpad.net/bugs/190744
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
