Re: Better soname linking

[Kurt Roeckx]

On Sun, Oct 25, 2009 at 03:00:27PM +0100, Jan Engelhardt wrote:
> Hello all,
> 
> 
> just today I stumbled over an issue where I think that the way 
> -version-info is encoded into the library and/or filename is not that 
> perfect after all.
> 
> ---8<---
> parent 741a9867eb71eb258ca1ed5b85bc7f03ce864195 (v2.2.6-150-g741a986)
> commit 34a9ed656c08625f975913b74bdc995ff2d18610
> Author: Jan Engelhardt <address@hidden>
> Date:   Sun Oct 25 13:26:58 2009 +0100
> 
> Create symlinks to all API versions and set soname to highest
> 
> -version-info 23:0:1 will create a libfoo.so.22.1.0 and there is a
> symlink libfoo.so.22 to it, so that programs originally linked for
> v22 continue to work with a v23 that implements APIs 22-23.
> 
> However, a program that uses functions from API 23 is still linked
> against libfoo.so.22. In other words, you could deploy this program
> on a system which only has libfoo.so.22.0.0 -- and package managers
> will happily do that without upgrading libfoo to so.22.1.0 --, thus
> potentially rendering essential system services unusable without a
> warning until it is too late:
> 
>  program: unknown symbol api23_function in libfoo.so.22
>  (or similar wording)

In Debian-based systems there we have 2 solutions for that:
- Make sure that the Depends field always has a version of
  >= 23
- Look at the symbols that got used, and only depend on
  >= 23 when symbols from that version are used.

In both cases we ship information with the library package
so that other packages linking to it can get the proper
information to add the right version requirements.

> This proposed solution includes changing the encode the highest
> version as the soname, so that new programs always link against the
> latest one. Appropriate symlinks for all API verisons will then be
> provided so that programs previously linked continue to work.

This would mean that for Depian packages we need to create
a package libfoo23 that Provides libfoo22.  The problem
with provides is that you can't have versioned depedencies
on them, so you need to make really sure there is never a reason
to depend on never versions like for instance libfoo.so.22.0.1.

An other solution would be a real libfoo22 package that Depends
on the libfoo23 package and just contains the symlink.  This
would allow the versioned depedencies.  But it creates a rather
empty binary package.

Anyway, we have solutions for that problem in place, and I don't
see a need for an other solution.


Kurt