[Openal-devel] Re: OpenAL & freealut Library Versioning

[Reinhard Tartler]

Sven Panne wrote:
>> Package 'Hurz' is uploaded and built against libfoo 1.1. 
>> Since the shlibs system did not detect new symbols, the 
>> binary will end up with a versioned dependency of [libfoo0 
>> (>= 1.0)], although it was built against version 1.1 (!).
>
> Here my problems understanding the Debian approach begin: How can we
> automatically know which symbols belong to 1.0 and which to 1.1? For
> glibc, this is stated explicitly by hand, IIRC.

This is in fact a manual process. The maintainer has to write a decent
shlibs file. Actually, there are tools to create those shlibs files.

The automatic part comes when building binary packages which link to the
shared library. dpkg-shlibdeps looks at the binaries using objdump, and
calculates the correct versioned dependencies for a given to be packaged
binary.

>> Then we upload 1.2, introducing new symbols. Package bar does 
>> not need to be rebuilt, as libfoo is ABI compatible 
>> (indicated by not bumping soname). 
>> 
>> Package bar2 get uploaded and built against version 1.2. The 
>> shlibs system ensures that the binary package bar2 ends up 
>> with a versioned dependency [libfoo0 (>=1.2)]. 
>
> Same problem as above: How do we know that we really need 1.2 and 1.1 or
> 1.0 are not enough?

This is something the maintainer has to note in the shlibs file. See
below for more documentation about this mechanism.

>> Now libfoo 2.0 is uploaded with bumped soname. It replaces 
>> the old package libfoo0 with the name libfoo1. All dependent 
>> packages get uninstallabe and need to be rebuilt against the 
>> new library ABI. The game restarts.
>
> OK, this seems to be the normal mechanism when the SONAME changes. I
> guess that the old version could be installed at the same time, correct?

Yes, it could be. We would have to create a new source package creating
the new binary package, so that we have actually both versions of the
library around. 

This is usually done with libraries with a large number of reverse
dependencies, in order to ensure a smooth transition to the newer
library version. Usually, it is easier to maintain only the latest
version of a library, though.

>> Everyone is happy. (needless to say that this shlib system 
>> makes nearly all of the work automatically, when used correctly).
>
> I'm still failing to see how this can be done automatically. Is there a
> document describing the Debian mechanism in a bit more detail?

Sure, it is described in detail in the Debian Policy Manual:
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps
http://www.debian.org/doc/debian-policy/ap-pkg-sourcepkg.html#s-pkg-dpkg-shlibdeps

Perhaps a bit easier to read is the Library Packaging Guide, espc. these
Parts:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonamenomodify
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#shlibsfile

Greetings,
	Reinhard