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

Sune Stolborg Vuorela <[email protected]> writes:
> Russ Allbery wrote:

>> I don't understand this objection. The reason why the name of the
>> package needs to change is that for a normal upgrade transition that
>> doesn't require a lockstep upgrade, you have to be able to install
>> version 1 and version 2 (SONAMEs) of the library at the same time, and
>> the only way that is possible in Debian's packaging system is if either
>> they are both included in the same package (usually not a good idea
>> since the different versions come from different versions of the source
>> package, and certainly not the common approach) or if the package name
>> is different.

> But sometimes you don't want to. Especially if  the libraries are not using 
> symbol versioning and the libraries are likely to be loaded into the same 
> process.

Could you expand on that a bit more? You're saying there's a case where
the SONAME of the library has changed, but you do not want to change the
name of the Debian package because... I'm not sure why? What are you
gaining by not changing the name of the package?

> You can do a lot of magic with shlibs/symbols files and provides

> e.g. you can in your symbols/shlibs file specify 
> libfoo (>>VERSION), libfoo-abi-7

> and have libfoo provide libfoo-abi-7.

> We have done that for libraries with exported-symbols-that-shouldn't-be-used-
> unless-you-are-special; see for example the qt6-base source package.

To be clear, I'm not going to second-guess how you manage a complex set of
C++ libraries like Qt, which pose a lot of challenges that are rather
unlike other shared library packages. I am happy for large, complex
ecosystems to carve out some exceptions, and if that needs some Policy
language blessing that, sure. There are a *lot* of factors in play that
combine to make Qt and KDE particularly complicated, such as the
difficulty using symbol versioning with C++ frameworks.

But I feel like either you're missing my point or I'm missing yours. The
Provides structure you describe above does nothing to allow the two
libraries to be coinstalled, which is what the original bug report claimed
(I thought).

Sure, if you want the two libraries to conflict, there are other
possibilities, and I can see how the Provides would be useful to provide,
for example, library transition tracking to have something to trigger on.
But we're already in the failure case at that point of not being able to
allow coinstallability. Provides is not a replacement for renaming the
package.

> It is also used for the kdepim (personal information management: 
> email,contacts,calendar,...) which has a lot of shared components without a 
> stable abi and from an upstream POV it is considered one release that just 
> comes in multiple tarballs.

Libraries that do not have a stable API and are internal to a particular
package aren't relevant to this discussion since this whole section of
Policy doesn't apply to them:

    This section deals only with public shared libraries: shared libraries
    that are placed in directories searched by the dynamic linker by
    default or which are intended to be linked against normally and
    possibly used by other, independent packages. Shared libraries that
    are internal to a particular package or that are only loaded as
    dynamic modules are not covered by this section and are not subject to
    its requirements.

Maybe the kdepim libraries fall into an awkward spot between the two?