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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs