Lenny fixes for opensaml2 and shibboleth-sp2

Russ Allbery rra at debian.org
Thu Dec 3 00:05:21 UTC 2009


"Scott Cantor" <cantor.2 at osu.edu> writes:
> Ferenc Wagner wrote on 2009-12-02:

>> The patched packages throw errors for the URLs kindly provided by
>> Scott, and otherwise seem to work normally.  I couldn't really stress
>> them, but I don't think that would have made any difference.  I'm not
>> clear on the soname change, though.

> I believe you bump the first digit, reset the middle to zero, but then
> increment the final digit. I believe the net effect of that should be to
> produce a lib that's still loadable by anything linked to the prior release,
> but that binaries linked against the new release will require.
>  
> (If not, it doesn't work the way I've understood it to for years.)

I believe that it will work that way on some platforms, but Linux has no
support at the dynamic linker level for both allowing previously-compiled
binaries to continue to link with the new shared library but requiring
newly built binaries to use only the newer library and not the older one.
This can only be implemented via symbol versioning, which requires
substantial additional configuration and isn't done via Libtool's
versioning interface.  SONAME changes on Linux are an all-or-nothing
affair: either everything has to be rebuilt, or everything built against
the new library will also dynamically link with the old library from the
perspective of the dynamic linker.

The dynamic linker therefore has to be supplemented with the package
management software, which on Debian is done with the shlibs
configuration.  This encodes in the package a dependency on the necessary
minimum version of the shared library package.

We can do the libtool version changes that are recommended in this case,
but the net effect on Linux is just to change the library file name from
something like:

    libfoo.so.1.0.0

to:

    libfoo.so.1.1.0

with no changes to the SONAME.  This has no real practical effect.

The Libtool documentation on versioning essentially describes an
optimistic superset of the facilities available in the dynamic linker on
all platforms and encourages you to give enough information to Libtool to
use all the facilities possibility available.  On most platforms, a lot of
that information is essentially thrown away since there's no way to
represent it.

I'm inclined to not worry about the Libtool versioning changing for that
reason, but we will want to add the code required to bump shlibs to ensure
that no one can install a newer libapache2-mod-shib2 without also updating
their libshibsp1 package.  And I suppose changing the Libtool versioning
doesn't really hurt anything, so maybe we should do it anyway just to be
formally correct.

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



More information about the Pkg-shibboleth-devel mailing list