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?
Regards, /Niels