On Sat, Jan 14, 2012 at 08:11:30PM +0100, Andy Polyakov wrote: > > I notice the shared library names (and SONAME) are 1.0.0 on the > > OpenSSL 1.0.1 libraries. > > It's unfortunate and should have been taken care of at 1.0.0 release. I > mean it should have been 1.0 or 10 or something. > > > I'd just like verification that this is intentional and we can expect > > binaries built against the 1.0.0 shared libs to run fine using the > > 1.0.1 shared libs. > > Incompatibilities will be treated as bugs, so I'd in fact encourage test > with binaries compiled with 1.0.0. To answer the specific question > numbering is not really intentional and should be fixed. It doesn't give > freedom to choose more intuitive 1.0 or 10, so presumably we are stuck > with 1.0.0. On side note, Redhat for one uses own numbering for > lib[crypto|ssl].so and should adhere to same number when upgrading to 1.0.1.
In Debian we use the *.so.1.0.0 soname. And so I would love to keep using that when moving to 1.0.1. I started the transition from the 0.9.8 soname to the 1.0.0 soname in April, and it's still ongoing. There are packages that are still linked against the old soname, and for various reasons can't be rebuild against the new version. I agree that *.so.1.0 would have been better as soname, but there is no point in changing it now. Also, there really is no reason why the soname should have any relation with the version of the library. The soname should change when the ABI changes. And if you're at version 2.0 of the library but the ABI is still compatible, there is no reason you can't keep using 1.0.0 as soname. In Debian I've also added symbol versioning to the library. In theory is should be possible for me to keep using the 1.0.0 soname if I add different versions of those symbols that get a different ABI. Kurt ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
