libsensors soname bump

libsensors soname bump

[Jean Delvare]

Hi Ondřej,

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.

In this specific case, I can't see what warranted such a change of
major library version change. From
lm-sensors/doc/developers/release_checklist:

  Remember: update main number when interface changes, minor if new
  functionality is added, and patch if only bugs are fixed.

In this case I can only see new functionality added, there is no
interface change. Therefore the correct value for SENSORS_API_VERSION
was 0x450, not 0x500. This would avoid the parallel maintenance and
installation of 2 versions of the library for several years to come.

Would you consider quickly releasing lm-sensors 3.5.1 with the proper
library version number, to save all that work to all application
authors/maintainers and distribution package maintainers?

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: libsensors soname bump

[Ondřej Lysoněk]

Hi Jean,

On 16. 12. 18 12:43, Jean Delvare wrote:
> Hi Ondřej,
> 
> 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).
[~/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.

Am I missing something?

Thanks.

Ondra

> 
> In this specific case, I can't see what warranted such a change of
> major library version change. From
> lm-sensors/doc/developers/release_checklist:
> 
>   Remember: update main number when interface changes, minor if new
>   functionality is added, and patch if only bugs are fixed.
> 
> In this case I can only see new functionality added, there is no
> interface change. Therefore the correct value for SENSORS_API_VERSION
> was 0x450, not 0x500. This would avoid the parallel maintenance and
> installation of 2 versions of the library for several years to come.
> 
> Would you consider quickly releasing lm-sensors 3.5.1 with the proper
> library version number, to save all that work to all application
> authors/maintainers and distribution package maintainers?
> 
> Thanks,
> 

Re: libsensors soname bump

[Ondřej Lysoněk]

On 17. 12. 18 10:46, Ondřej Lysoněk wrote:
> Hi Jean,
> 
> On 16. 12. 18 12:43, Jean Delvare wrote:
>> Hi Ondřej,
>>
>> 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).
> [~/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.
> 
> Am I missing something?

I mean, I would love to revert the soname change, however doing so now
seems like a bad thing to do - people may have already adopted
lm_sensors 3.5.0. So I'd like to avoid reverting the change unless there
is a good justification to do so.

Ondřej Lysoněk

Re: libsensors soname bump

[Jean Delvare]

On Mon, 17 Dec 2018 11:35:46 +0100, Ondřej Lysoněk wrote:
> I mean, I would love to revert the soname change, however doing so now
> seems like a bad thing to do - people may have already adopted
> lm_sensors 3.5.0. So I'd like to avoid reverting the change unless there
> is a good justification to do so.

It's not in Debian yet:
https://packages.debian.org/sid/lm-sensors

Gentoo have picked it but it is still in testing:
https://packages.gentoo.org/packages/sys-apps/lm_sensors

You'll know better than I do about Fedora.

For openSUSE, I have packaged lm-sensors 3.5.0 but with a patch
reverting the undue soname change. I used "4.5.0" instead. I intend to
carry this patch for as long as I have to. This goes against our policy
of sticking to upstream as much as possible, but in this specific case,
I consider it the least of 2 evils.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: libsensors soname bump

[Aurelien Jarno]

On 2018-12-17 11:59, Jean Delvare wrote:
> On Mon, 17 Dec 2018 11:35:46 +0100, Ondřej Lysoněk wrote:
> > I mean, I would love to revert the soname change, however doing so now
> > seems like a bad thing to do - people may have already adopted
> > lm_sensors 3.5.0. So I'd like to avoid reverting the change unless there
> > is a good justification to do so.
> 
> It's not in Debian yet:
> https://packages.debian.org/sid/lm-sensors

It's available in the experimental suite with the soname change:
https://packages.debian.org/experimental/lm-sensors

And it's waiting for a transition slot to rebuild all the
reverse dependencies in sid:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915790

So on the Debian side, there is still time to revert the soname change.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Re: libsensors soname bump

[Ondřej Lysoněk]

Hi Laurent,

I see that you're the lm_sensors maintainer in Arch Linux. I understand
you recently upgraded lm_sensors to 3.5.0 in Arch, while keeping the
upstream soname change of libsensors to libsensors.so.5.

As the soname change was undue, we're currently considering reverting it
(see below, the whole thread should be available on spinics [1]). Would
that pose a major problem for you? Have the dependent packages in Arch
already been rebuilt?

Thanks!

[1] https://www.spinics.net/lists/linux-hwmon/msg04837.html

Best regards
Ondřej Lysoněk

On 17. 12. 18 12:27, Aurelien Jarno wrote:
> On 2018-12-17 11:59, Jean Delvare wrote:
>> On Mon, 17 Dec 2018 11:35:46 +0100, Ondřej Lysoněk wrote:
>>> I mean, I would love to revert the soname change, however doing so now
>>> seems like a bad thing to do - people may have already adopted
>>> lm_sensors 3.5.0. So I'd like to avoid reverting the change unless there
>>> is a good justification to do so.
>>
>> It's not in Debian yet:
>> https://packages.debian.org/sid/lm-sensors
> 
> It's available in the experimental suite with the soname change:
> https://packages.debian.org/experimental/lm-sensors
> 
> And it's waiting for a transition slot to rebuild all the
> reverse dependencies in sid:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915790
> 
> So on the Debian side, there is still time to revert the soname change.
> 
> Aurelien
> 

Re: libsensors soname bump

[Ondřej Lysoněk]

Hi lm-sensors list,

We're currently considering reverting the undue libsensors soname change
that happened in lm_sensors 3.5.0 (see below, the whole thread should be
available on spinics [1]). Would that pose a major problem for anyone?

Thanks!

[1] https://www.spinics.net/lists/linux-hwmon/msg04837.html

Best regards
Ondřej Lysoněk

On 17. 12. 18 12:27, Aurelien Jarno wrote:
> On 2018-12-17 11:59, Jean Delvare wrote:
>> On Mon, 17 Dec 2018 11:35:46 +0100, Ondřej Lysoněk wrote:
>>> I mean, I would love to revert the soname change, however doing so now
>>> seems like a bad thing to do - people may have already adopted
>>> lm_sensors 3.5.0. So I'd like to avoid reverting the change unless there
>>> is a good justification to do so.
>>
>> It's not in Debian yet:
>> https://packages.debian.org/sid/lm-sensors
> 
> It's available in the experimental suite with the soname change:
> https://packages.debian.org/experimental/lm-sensors
> 
> And it's waiting for a transition slot to rebuild all the
> reverse dependencies in sid:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915790
> 
> So on the Debian side, there is still time to revert the soname change.
> 
> Aurelien
> 

Re: libsensors soname bump

[Jean Delvare]

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

Re: libsensors soname bump

[Ondřej Lysoněk]

Hi Jean,

On 16. 12. 18 12:43, Jean Delvare wrote:
> Hi Ondřej,
> 
> 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.
> 
> In this specific case, I can't see what warranted such a change of
> major library version change. From
> lm-sensors/doc/developers/release_checklist:
> 
>   Remember: update main number when interface changes, minor if new
>   functionality is added, and patch if only bugs are fixed.
> 
> In this case I can only see new functionality added, there is no
> interface change. Therefore the correct value for SENSORS_API_VERSION
> was 0x450, not 0x500. This would avoid the parallel maintenance and
> installation of 2 versions of the library for several years to come.
> 
> Would you consider quickly releasing lm-sensors 3.5.1 with the proper
> library version number, to save all that work to all application
> authors/maintainers and distribution package maintainers?

I did consider it, but I'm afraid I can't do this, sorry. I'm afraid it
would cause more problems than it would solve.

lm_sensors 3.5.0 has already been picked up by several distributions
[1], and at least Arch Linux, Slackware and Gentoo have already rebuilt
the dependent packages. It feels wrong to force the people, who already
picked up the new version, to do the work again. I've spoken to the
Gentoo maintainer and he's not thrilled about doing that. I'm really not
looking forward to another batch of angry breakage reports after doing
another soname change.

Doing the 3.5.1 release would also mean that everyone using 3.5.0 would
have to upgrade, otherwise the values of the SENSORS_API_VERSION macro
would be different on different systems, forcing users of that macro to
deal with the mess.

I suggest that you use the patch that reverts the soname change in
OpenSUSE, but keep the new SENSORS_API_VERSION so that it remains
consistent with other distros.

Thanks for understanding.

[1] https://repology.org/metapackage/lm-sensors/versions

Best regards
Ondřej Lysoněk

Re: libsensors soname bump

[Jean Delvare]

Hi Ondřej,

On Tue, 18 Dec 2018 18:06:00 +0100, Ondřej Lysoněk wrote:
> On 16. 12. 18 12:43, Jean Delvare wrote:
> > Would you consider quickly releasing lm-sensors 3.5.1 with the proper
> > library version number, to save all that work to all application
> > authors/maintainers and distribution package maintainers?  
> 
> I did consider it, but I'm afraid I can't do this, sorry. I'm afraid it
> would cause more problems than it would solve.
> 
> lm_sensors 3.5.0 has already been picked up by several distributions
> [1], and at least Arch Linux, Slackware and Gentoo have already rebuilt
> the dependent packages. It feels wrong to force the people, who already
> picked up the new version, to do the work again. I've spoken to the
> Gentoo maintainer and he's not thrilled about doing that. I'm really not
> looking forward to another batch of angry breakage reports after doing
> another soname change.
> 
> Doing the 3.5.1 release would also mean that everyone using 3.5.0 would
> have to upgrade, otherwise the values of the SENSORS_API_VERSION macro
> would be different on different systems, forcing users of that macro to
> deal with the mess.

OK. Thank you for taking the time to investigate the option. I
understand and respect your decision.

> I suggest that you use the patch that reverts the soname change in
> OpenSUSE, but keep the new SENSORS_API_VERSION so that it remains
> consistent with other distros.

You are right. I have reverted the change to SENSORS_API_VERSION from
my SUSE-local patch. While there was some beauty in having a
"structured" SENSORS_API_VERSION, there is a lot more value in using
the same value as upstream.

-- 
Jean Delvare
SUSE L3 Support