On Tue, Mar 27, 2018 at 11:04:28PM +0200, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@redhat.com writes:
When we initially introduced symbol versioning in nettle we bundled all symbols from the library in a single version. That means that new symbols added to a release like nettle_get_hashes() may cause issues like this: https://bugzilla.redhat.com/show_bug.cgi?id=1549190
I aim to ensure that a program compiled with nettle version x should work fine when linked with nettle version x+1, with exceptions told to the linker by changing the soname. When I talk about backwards compatibility, it's always this case I have in mind.
In general, I don't try to support compiling a program using libnettle version x, and then linking it with libnettle version x-1, and I think that should be referred to as forward compatibility rather backward comatibility. (I might try if I do releases with only bug fixes, typically with unchanged minor version).
Maybe that's the old-fashioned way, but if you want to be sure the program can link successfully with nettle version x-1, you need to compile it using nettle x-1 development files.
So if a distro builds stuff using nettle version x on the build machine, the dependency on the resulting binary packages should express that it needs shared nettle libraries which
(i) correspond to a package version >= x, and (ii) uses the same soname.
The underlying issue is in rpm-based systems which detect which symbols exist in which library version based on the version. That way, when a dependency is tracked, the version with the right symbol will be retrieved.
That's clever, and should work fine for packages that make the extra effort to have fine-grained symbol versions, but it can't be the *only* way to handle libraries with rpm?
The traditional way is for developers to update the dependancies to have an explicit version against the library they require. eg if libvirt requires some symbol introduced in nettle x.y, the maintainer would add
Requires: nettle >= x.y
the problem is that humans are fallible and so these versioned dependancies frequently get missed, because package maintainers don't often have accurate info on which min version is needed by a build. By adding fine grained symbol versioning to the nettle library, humans are taken out of the loop, in favour of automation in the toolchain. The linker embeds elf versions in the downstream app linking to nettle, so the linker will refuse to load against an outdated nettle. RPM automatically extracts these versions and turns then into correct versioned dependancies ensuring old versions can't be installed in the first place. The only scope for errors here is when the nettle developers are creating the symbol version file, and this is pretty minor IME maintaining such version files for libvirt.
Regards, Daniel