Openssl-1.0.1a to openssl-1.0.1d-r1 install their libraries as is they were version 1.0.0. This is of course confusing and creates subtle bugs as the libraries are not flagged as needing rebuilding on upgrade. Reproducible: Always Steps to Reproduce: 1.upgrade from openssl < 1.0.1 to 1.0.1 all current entries in tree 2. 3. Expected Results: Libries should be named as per packager version
You need to be more specific about what the actual problem is. See "How does the versioning scheme work?" in FAQ in the tarball.
The library for v1.0.0 is named libssl.so-1.0.0 as you would expect. The library that the v1.0.1 series installs is named the *SAME* as the v1.0.0 series. Because they are named the same, the ebuild magic doesn't list them for rebuild. To be clear, v1.0.1 installs as 1.0.0 which is wrong as far as I can see. The FAQ states that this means it is a "minor" change as one would expect. What is not clear is if different minor versions should be naming their libraries the same - and as one is v1.0.0 and the other v1.0.1, I would expect thats a bug/mistake ... especially if a system wide revdep-rebuild for libssl and libcrypto is needed to fix the problems this caused me (primarily apache and php) when I downgraded. The FAQ says minor changes retain binary compatibility ... but can contain new features which may be what "bit" me. Hopefully this clarifies the problem. BillK
Again, list specific problems. That FAQ makes it clear, that the library version between 1.0.X versions is not changed *deliberately*.
(In reply to comment #2) > for libssl and libcrypto is needed to fix the problems this caused me > (primarily apache and php) when I downgraded. The FAQ says minor changes when you downgraded? binary ABI is guaranteed to be only compatible forwards, not backwards that's your mistake there
