Bug#509933: versioning SONAMEs of shared libraries is not clearly recommended

[Russ Allbery <rra@debian.org>]

Emilio Pozuelo Monfort <pochu27@gmail.com> writes:
> On 13/07/10 04:11, Russ Allbery wrote:

>> +	<p>
>> +	  The run-time shared library must be placed in a package
>> +	  whose name changes whenever the <tt>SONAME</tt> of the shared
>> +	  library changes.  This allows several versions of the shared
>> +	  library to be installed at the same time, allowing installation
>> +	  of the new version of the shared library without immediately
>> +	  breaking binaries that depend on the old version.  Normally, the

> Should this also mention that every file's absolute path in that package
> should change whenever the SONAME changes (either because the file is
> versioned or because it's in a versioned path), with the exception of
> /usr/share/doc/$package?

We already did, which is the only reason why it's not in this patch.  It's
in the next section down:

     If your package contains files whose names do not change with each
     change in the library shared object version, you must not put them in
     the shared library package.  Otherwise, several versions of the shared
     library cannot be installed at the same time without filename clashes,
     making upgrades and transitions unnecessarily difficult.

>> +	<p>
>> +	  Every time the shared library ABI changes in a way that may
>> +	  break binaries linked against older versions of the shared
>> +	  library, the <tt>SONAME</tt> of the library and the
>> +	  corresponding name for the binary package containing the runtime
>> +	  shared library should change.  Normally, this means

> Any reason this is a should and not a must?

Yeah, there have been cases where we've decided to fix the breakage
without changing the SONAME.  For example, upstream MIT Kerberos removed
some symbols from libkrb5 without changing the SONAME, but those symbols
were never prototyped in the headers and had been documented as private.
Rather than diverging from upstream's SONAME, we looked through the whole
distribution to find anything that was using those symbols, fixed bugs in
four other packages, and went forward without an SONAME change.

This normally isn't what you want to do, but there are cases where
portability of SONAMEs between distributions is particularly important
(consider libraries such as libpng, libz, or the X libraries, for
instance), and it's occasionally worth handling breakage in other ways.

> Seconded.

Thanks!  This has now been merged for the next release.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>