Re: libsensors soname bump

[Jean Delvare <jdelvare@suse.de>]

On Mon, 17 Dec 2018 10:46:43 +0100, Ondřej Lysoněk wrote:
> On 16. 12. 18 12:43, Jean Delvare wrote:
> > You have recently released lm-sensors 3.5.0 with a new soname for
> > libsensors:
> > 
> > -LIBMAINVER := 4
> > -LIBMINORVER := 4.0
> > +LIBMAINVER := 5
> > +LIBMINORVER := 0.0
> > 
> > -#define SENSORS_API_VERSION            0x440
> > +#define SENSORS_API_VERSION            0x500
> > 
> > This is declaring the new library as incompatible with the previous
> > version, meaning that distributions will have to build and ship both
> > libsensors4 and libsensors5 for a long time until all applications have
> > been updated and rebuilt to link with the new library. This is a
> > significant effort for the whole community and should only be done when
> > necessary.  
> 
> I thought there was an ABI change, which would warrant a soname bump. Or
> am I wrong in thinking that? I was mistaken however and I'm sorry about
> that, there was no ABI change.
> 
> I don't see why distributions would have to ship two versions of the
> library. The *name* of the library didn't change, it's still libsensors
> (not libsensors4 or libsensors5).

But the packages as they exist today, they link with libsensors.so.4,
not libsensors.so:

$ rpm -q --requires sensors | grep sensors
libsensors.so.4()(64bit)

Having only one library works only if you update the whole system at
once. That can work in some specific cases I suppose, but in practice
can be hard to achieve in a complex ecosystem without breaking things
"temporarily". That's really not the kind of thing users enjoy. The
whole point of using a distribution is that things just work, all the
time.

So the standard way to handle major library version changes is to
provide both in parallel at first, then migrate all applications, and
once all applications have been migrated, deprecate the old library.
And after a few years, remove that old library.

> [~/git/lm-sensors]$ make
> ...
> [~/git/lm-sensors]$ ls lib/ | grep libsensors.so
> libsensors.so
> libsensors.so.5
> libsensors.so.5.0.0
> 
> So all distros need to do is rebuild dependent packages. No changes to
> other packages should be required.

Well, that alone is already pretty painful. Having to rebuild, ship,
download and install all these applications is a major waste of
resources. That's no less that 98 packages for my distribution. The
whole point of having shared libraries is to make it possible to update
one package and leave the rest unchanged. Changing the soname breaks
that possibility.

For us (openSUSE) it would also require changing the BuildRequires of
all these applications from "libsensors4-devel" to "libsensors5-devel".
Maybe that package should be named "libsensors-devel" instead, I'm not
sure why we versioned it, I see that most libraries are not doing that.
Maybe we had to when transitioning from lm-sensors 2 to lm-sensors 3. I
don't remember the details.

> Am I missing something?

There are also all the 3rd party applications. Either shipped as
binaries by proprietary software editors, or built in the Open Build
Service. Changing the library version with no reason breaks
compatibility with them.

Without the soname change, it is possible for a user to cherry-pick a
package update they need, independent of what the distribution has. For
example, a user may need the latest version of libsensors because it
fixes a bug for them. They could get it from the Open Build Service
easily... But now they won't be able to install it, because the soname
is incompatible with their current distribution. They would either have
to pull all the packages using libsensors from the Open Build System
(which can be very painful if some of these packages also have complex
dependencies), or changing distributions altogether. This is opposite
to the flexibility we intend to provide to our users.

The major version of a library should only ever be changed for
incompatible changes, that is, if an application built for the old
version of the library will fail to run with the new version of the
library. If this is not the case then then major version must stay the
same.

Thanks,
-- 
Jean Delvare
SUSE L3 Support