Comment 38 for bug 190744

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.