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

[sfrost@snowman.net]

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

* Kurt D. Zeilenga (Kurt@OpenLDAP.org) wrote:
> Does anybody have experience with doing something like:
> 	-release 2.2 -version-info 1:0:0
>=20
> That is, do such constructions works on most platforms.
> Libtool seems to construct:
>   # Names of this library.
>   library_names=3D'liblber-2.2.so.1 liblber-2.2.so liblber.so'
>=20
>   # The name of the static archive.
>   old_library=3D'liblber.a'
>=20
> If this works, this might met our requirements.  Comments?

Alright, this doesn't really work because it means that -llber could
actually mean any of the versions which is generally not what you really
want.  You should be making a distinction between the major releases in
OpenLDAP because in general you don't expect people to be able to move
=66rom 2.0 to 2.2 w/o  changing something (API differences).  What you
probably want to do is close though, and is very similar to what the
Sleepcat (libdb) folks do now-

Use a different library name for the major versions (2.0, 2.1, 2.2, 3.0,
etc) and then keep the API the same through those but change the ABI as
necessary and update *that* using the regular -version-info method.
This will give you libraries like:
liblber-2.2.so.0, liblber-2.2.so.1 with a link for liblber-2.2.so
liblber-2.3.so.0, liblber-2.3.so.1 with a link for liblber-2.3.so, etc.

Note that you *won't* have a 'liblber.so' link and therefore won't be
able to do '-llber', but you don't really want people doing that anyway
because they're different APIs.  You also won't be using '-release' at
all.

Your idea above probably wouldn't actually be a problem for Debian since
we don't allow people to try and have multiple -dev packages installed
at the same time (because of the .so symlink) anyway, but it wouldn't
really be much fun for us to deal with in the packaging.  It's also not
something we'd recommend.

What I think we probably *would* do is introduce symbol versioning which
then followed the SONAME, so something like- LDAP_2_2_SO_0,=20
LDAP_2_2_SO_1.  This would mean that a given application could link=20
against a library which linked against LDAP_2_2_0 and link itself=20
against LDAP_2_2_SO_1 and not have any problems.  It should also make it
clear that the symbol version is derived from the SONAME (as opposted to
the release version).

Of course, changing the ABI in a maintenance release should still be
pretty rare, and made *very* clear (it should really be noted in the
release notes, at the very least) when it does happen.  It's also going
to be something of a pain for the Debian maintainers to deal with
because we're going to have to support both versions which also means
we're going to be having seperate source packages for each ABI version.

It'd be much nicer to either use versioned symbols or just require that
the ABI version not change in maintenance releases.

	Stephen

--sHhmzMatm85/eqYu
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)

iD8DBQFAYZ69rzgMPqB3kigRAm+uAKCX/OamxwSEhsmu7+/91ar6pVqsmgCdEa0G
OMpJxgeFTHGVQQ6fQUzbGqU=
=xj/T
-----END PGP SIGNATURE-----

--sHhmzMatm85/eqYu--