Bug#1136641: debian-policy: do not require shared libraries to change package name with soname changes

Hi,

On Fri, 2026-05-15 at 13:00 +0200, Bill Allombert wrote:
> On Thu, May 14, 2026 at 10:46:59AM +0200, Ansgar wrote:
> > 2. Coinstallability should be mentioned as a concern for libraries
> > with many reverse dependencies, but should explictly state that this
> > requires the entire dependency chain to be coinstallable. Note that
> > "Depends: libfoo-common (>= X)" runs into the risk that newer
> > libfoo-common packages break older library versions and are safe only
> > when extraordinary care is taken; the same is true for
> > "libfoo-bin". (One could use libfooX-common, libfooX-bin packages
> > where data and helper binaries are installed into paths that change
> > with the SONAME such as /usr/lib/libfooX/libfoo-helper.)
> 
> During an upgrade even if the file libfoo.so.N is removed, programs
> linked against libfoo.so.N might still be running and might still attempt to
> access files in libfoo-common or libfoo-bin.
> So the new libfoo-common/libfoo-bin still need to be compatible with the old
> libfoo.so.N, 

Sorry, programs *will* in general *not* *work* when their environment
is updated while they are running. For most programs this is undefined
behavior.

A requirement that running instances of Firefox/Libreoffice/* will
continue to work while their packages are upgraded (or even removed) is
not realistic. It only works by luck for trivial programs (and nobody
tests this).

Ansgar