[Date Prev][Date Next]
Re: Using libtool -release versus -version-info breaks packages (ITS#3035)
Content-Type: text/plain; charset=us-ascii
* Kurt D. Zeilenga (Kurt@OpenLDAP.org) wrote:
> Reducing ABI changes in released versions is all well and good.
> However, some ABI changes are unavoidable. That's why ABI
> versioning exists. However, at present, we seem to having
> problems coming up with a workable scheme.
I'm glad to hear that it doesn't sound like your intent is to break
binary compatibility between each released version. Having to change
the ABI on a released version every once in a while is understandable
when there's a long release cycle for major releases.
> My question to those who prefer we go back to a version-info
> scheme is to provide a suggested numbering scheme (with no
> changes to the library names (see requirements in my previous
> post)) for 2.2, 2.3, and 2.x (and if you are really forward
> thinker, 3.x) branches which support inter-branch ABI changes.
I'm guessing you mean 'intra-branch' ABI changes, as in those inside a
given major release (ie: 2.2). Certainly one option, as I mentioned
previously, would be to use versioned symbols. I realize this isn't
possible on all architectures but it'd be a great thing to have on the
architectures where it's available. I expect we'll probably actually
implement symbol versioning for the Debian OpenLDAP packages as soon as
libtool's upstream includes the patch to automate symbol versioning.
It's not as nice as if OpenLDAP upstream did it themselves on a
per-symbol basis similar to what glibc does but it will help in the
situations I outlined previously.
As for the numbering scheme, I'm actually inclined to suggest a very
simple one- a simple counter that's not derived from the OpenLDAP
version number. Chances are it'll be a very long time before you get to
the '255' number that's apparently causing some concern. It wouldn't be
as obvious by looking at just the SONAME what OpenLDAP version it came
=66rom but certainly a cross-reference could be maintained easily.
This is just off the top of my head, I'll discuss this with the other
Debian OpenLDAP maintainers and Debian release managers who have to deal
with these library issues across a large set of packages much more often
than I do and see what suggestions they have and get back to you.
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----