Description of problem: GNU linker has an ability to use version-script for distinguishing between backward compatible changes. http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_25.html For backward incompatible changes SONAME should be bumped. New functions should not be added to old versions but to the the new version. It is usually bound to upstream release. However new functions are added to nettle to the same VERSION, which prevents auto-detection of dependencies done by rpm/dpkg. How reproducible: deterministic Steps to Reproduce: 1. dnf install -e0 -d0 -y nettle binutils 2. rpm -q nettle 3. objdump -p /usr/lib64/libnettle.so.6 | grep -A5 "Version definitions" 4. objdump -T /usr/lib64/libnettle.so.6 | grep nettle_get_hashes 5. dnf update --enablerepo=updates-testing -e0 -d0 -y nettle 6. objdump -p /usr/lib64/libnettle.so.6 | grep -A5 "Version definitions" 7. objdump -T /usr/lib64/libnettle.so.6 | grep nettle_get_hashes Actual results: sh# objdump -p /usr/lib64/libnettle.so.6 | grep -A5 "Version definitions" Version definitions: 1 0x01 0x0df16e86 libnettle.so.6 2 0x00 0x0a991006 NETTLE_6 Version References: required from libc.so.6: sh# objdump -T /usr/lib64/libnettle.so.6 | grep nettle_get_hashes sh# echo $? 1 sh# rpm -ql nettle | grep libnettle.so /usr/lib64/libnettle.so.6 /usr/lib64/libnettle.so.6.3 sh# dnf update --enablerepo=updates-testing -e0 -d0 -y nettle sh# objdump -p /usr/lib64/libnettle.so.6 | grep -A5 "Version definitions" Version definitions: 1 0x01 0x0df16e86 libnettle.so.6 2 0x00 0x0a991006 NETTLE_6 Version References: required from libc.so.6: sh# objdump -T /usr/lib64/libnettle.so.6 | grep nettle_get_hashes 0000000000018460 g DF .text 0000000000000008 NETTLE_6 nettle_get_hashes sh# rpm -ql nettle | grep libnettle.so /usr/lib64/libnettle.so.6 /usr/lib64/libnettle.so.6.4 Expected results: sh# objdump -p /usr/lib64/libnettle.so.6 | grep -A5 "Version definitions" Version definitions: 1 0x01 0x0df16e86 libnettle.so.6 2 0x00 0x0a991006 NETTLE_6 Version References: required from libc.so.6: sh# objdump -T /usr/lib64/libnettle.so.6 | grep nettle_get_hashes sh# echo $? 1 sh# rpm -ql nettle | grep libnettle.so /usr/lib64/libnettle.so.6 /usr/lib64/libnettle.so.6.3 sh# dnf update --enablerepo=updates-testing -e0 -d0 -y nettle sh# objdump -p /usr/lib64/libnettle.so.6 | grep -A5 "Version definitions" Version definitions: 1 0x01 0x0df16e86 libnettle.so.6 2 0x00 0x0a991006 NETTLE_6 3 0x00 0x0b671006 NETTLE_6.4 Version References: required from libc.so.6: sh# objdump -T /usr/lib64/libnettle.so.6 | grep nettle_get_hashes 0000000000018460 g DF .text 0000000000000008 NETTLE_6.4 nettle_get_hashes sh# rpm -ql nettle | grep libnettle.so /usr/lib64/libnettle.so.6 /usr/lib64/libnettle.so.6.4 Additional info: It caused issues in dnsmasq https://bugzilla.redhat.com/show_bug.cgi?id=1556888
I know that there is a trivial way to add explicit requires in other projects. But it is better to rely on binutils and automatic detection of symbols done by rpm. So it would be good if you could persuade upstream to use version-script properly and do not add new symbols to versions which were already released. BTW you can also check 3rd section in https://www.akkadia.org/drepper/dsohowto.pdf
Note: It is not required to enable updates-testing for installing nettle-3.4-1.fc27.x86_64. It is already in updates for quite a log. However it does not change fact the new symbols were added to old version.
I have already asked upstream to consider that kind of versioning. No buy-in so far (nor I can link to my email as nettle ML archives do not include recent emails)
*** This bug has been marked as a duplicate of bug 1549190 ***
Is that "no buy-in" as in nobody has responded, or is it that they actively *want* to do it wrong? The latter would be a somewhat concerning attitude, especially in a crypto library. We expect attention to detail in all things.
No response. Note that the strict versioning script, which includes separate versions depending on when the symbol was introduced, is not widely accepted as necessary, and it is not easy to automate [1]. The reason is that it only affects rpm-based systems. deb-based or other systems really have no gain as they don't use that information. [1]. see also https://www.libssh.org/archive/libssh/2018-03/0000011.html