[Openal-devel] Re: OpenAL & freealut Library Versioning
siretart at tauware.de
Tue Feb 21 01:55:13 PST 2006
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
>> 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
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:
Perhaps a bit easier to read is the Library Packaging Guide, espc. these
More information about the Openal-devel