Re: Using libtool -release versus -version-info breaks packages (ITS#3035)

[sfrost@snowman.net]

--T4UkA7JqaRL9g7KR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Kurt@OpenLDAP.org (Kurt@OpenLDAP.org) wrote:
> Your comments focus mostly on how to avoid making incompatible
> changes.  However, there will be incompatible changes.  We
> need to ensure that when multiple libraries are available to the
> dynamic linker that incorrect ones are not chosen.  This is
> what using -release does for us.

If you can't manage to not make incompatible changes for a reasonable
amount of time then you shouldn't be making a library.  For development
it's fine- have a development branch and just use the same SONAME.  For
releases, no, it's not reasonable or acceptable.  What you are ensuring
by doing this is that users will *much* more often end up trying to run
binaries which link in multiple incompatible versions of a library.
This is exactly the same problem we've run into w/ OpenSSL and it's been
a huge pain in the ass because they aren't competent enough to figure
out what an ABI change is.

The way you basically screw your users over a barrel by doing this is
through indirect linking, which happens quite often, *especially* for
such a low-level library as libldap.  It goes like this:

A builds libldap 2.1.25
B builds libX which uses libldap 2.1.25
C builds appY which uses libX and libldap 2.1.25.

As long as libX compiles against the same libldap that appY does, you're
fine.  This doesn't last very long though-

OpenLDAP 2.1.26 comes out
A builds libldap 2.1.26
New version of appY comes out
C rebuilds appY against the unchanged libX and libldap 2.1.26

Yay, now appY segfaults all over the place because both libldap 2.1.25
and libldap 2.1.26 get loaded and the sybmols collide.

Now, this is mitigated slightly by slowing down the rate of ABI changes
so that it's only changed between major releases.  The problem still
exists, but at least you don't run into it as often and when you do you
just have to recompile everything.  Very annoying, but much more doable
when it's rare.

Of course, the correct way to handle this is to use versioned symbols.
That way you can have a single library/SONAME which supports both old
programs/libraries and new programs/libraries.  If you can't handle that
then you should at least stamp a version on each major library/SONAME so
that when the two libraries get pulled in they don't collide.

Doing this for every minor version would be it's own hell, of course,=20
because you'd have to have a package for every minor reversion of
OpenLDAP and you'd have to *support* every minor revision of OpenLDAP.
This gets *very* ugly and makes maintenance a nightmare.  This would
basically be equivilant to staticlly linking.  Consider a security bug
in version 2.2.45, it'd probably be in 2.2.1-2.2.44 too and you'd have
to issue an update for *all* of them.

This also would grow the memory usage of applications because each
library it linked to might be loading in it's own version of libldap.
These things are not acceptable.

Please try to understand and to consider the implications of your
change.  Almost certainly we would need to revert it in order to be able
to continue to maintain OpenLDAP reasonably.  This would likely involve
a fork of OpenLDAP which I'd be lothe to do except as a last resort.
Your solution also certainly does not solve the problem you are=20
outlining.

	Thanks,

		Stephen

--T4UkA7JqaRL9g7KR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAYJkirzgMPqB3kigRAh7UAJ9C7jZgcscox1Q3piMcXyubVzvLgACgha9K
CdmjoZHqBkUdc4o892iEKmM=
=qJdr
-----END PGP SIGNATURE-----

--T4UkA7JqaRL9g7KR--