All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: "Ondřej Lysoněk" <olysonek@redhat.com>
Cc: linux-hwmon@vger.kernel.org,
	Aurelien Jarno <aurelien@aurel32.net>,
	lordheavym@gmail.com, lm-sensors@vger.kernel.org
Subject: Re: libsensors soname bump
Date: Wed, 19 Dec 2018 16:10:33 +0100	[thread overview]
Message-ID: <20181219161033.348b8e94@endymion> (raw)
In-Reply-To: <05037889-f0ce-8f5b-2a35-b85170443883@redhat.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <jdelvare@suse.de>
To: "Ondřej Lysoněk" <olysonek@redhat.com>
Cc: linux-hwmon@vger.kernel.org,
	Aurelien Jarno <aurelien@aurel32.net>,
	lordheavym@gmail.com, lm-sensors@vger.kernel.org
Subject: Re: libsensors soname bump
Date: Wed, 19 Dec 2018 15:10:33 +0000	[thread overview]
Message-ID: <20181219161033.348b8e94@endymion> (raw)
In-Reply-To: <05037889-f0ce-8f5b-2a35-b85170443883@redhat.com>

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

  reply	other threads:[~2018-12-19 15:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-16 11:43 libsensors soname bump Jean Delvare
2018-12-17  9:46 ` Ondřej Lysoněk
2018-12-17 10:35   ` Ondřej Lysoněk
2018-12-17 10:59     ` Jean Delvare
2018-12-17 11:27       ` Aurelien Jarno
2018-12-17 11:48         ` Ondřej Lysoněk
2018-12-17 12:06         ` Ondřej Lysoněk
2018-12-17 12:06           ` Ondřej Lysoněk
2018-12-17 10:48   ` Jean Delvare
2018-12-18 17:06 ` Ondřej Lysoněk
2018-12-18 17:06   ` Ondřej Lysoněk
2018-12-19 15:10   ` Jean Delvare [this message]
2018-12-19 15:10     ` Jean Delvare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181219161033.348b8e94@endymion \
    --to=jdelvare@suse.de \
    --cc=aurelien@aurel32.net \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=lm-sensors@vger.kernel.org \
    --cc=lordheavym@gmail.com \
    --cc=olysonek@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.