Hi,

On 26/07/17 16:18, Dirk Eddelbuettel wrote:
> On 26 July 2017 at 15:36, James Cowgill wrote:
> | On 26/07/17 15:10, Dirk Eddelbuettel wrote:
> | > On 26 July 2017 at 14:48, James Cowgill wrote:
> | > | On 26/07/17 14:39, Dirk Eddelbuettel wrote:
> | > | > On 26 July 2017 at 15:18, Julien Cristau wrote:
> | > | > | Control: reopen -1
> | > | > | 
> | > | > | On Wed, Jul 26, 2017 at 12:57:55 +0100, James Cowgill wrote:
> | > | > | 
> | > | > | > Hi,
> | > | > | > 
> | > | > | > On 26/07/17 12:32, Dirk Eddelbuettel wrote:
> | > | > | > > On 26 July 2017 at 13:14, Michal Politowski wrote:
> | > | > | > > | Package: libgsl2
> | > | > | > > | Version: 2.4+dfsg-1
> | > | > | > > | Severity: important
> | > | > | > > | 
> | > | > | > > | libgsl2 2.3+dfsg-1 contains 
> /usr/lib/i386-linux-gnu/libgsl.so.19 (on i386)
> | > | > | > > | libgsl2 2.4+dfsg-1 contains 
> /usr/lib/i386-linux-gnu/libgsl.so.23
> | > | > | > > | this breaks packages depending on libgsl2.
> | > | > | > > | 
> | > | > | > > | If the soname changed, package name must change too.
> | > | > | > > 
> | > | > | > > Right.  I'll change the soname.
> | > | > | > 
> | > | > | > From NEWS:
> | > | > | > > ** removed routines which were deprecated in v2.1:
> | > | > | > >      gsl_bspline_deriv_alloc
> | > | > | > >      gsl_bspline_deriv_free
> | > | > | > 
> | > | > | > Isn't this an ABI break? If so, upstream changing the SONAME was 
> correct
> | > | > | > and the package should be renamed (instead of reusing the old
> | > | > | > incompatible SONAME).
> | > | > | > 
> | > | > | Yes.  You need to either bump SONAME *and* change package name, or 
> keep
> | > | > | the package name and SONAME but revert the ABI breakage.  There's no
> | > | > | option where you get to break ABI but keep the SONAME and/or package
> | > | > | name.
> | > | > 
> | > | > Allow me to quote myself from a reply I just sent a minute ago:
> | > | > 
> | > | >    We have this discussion on every release.  Look what is in 
> (upstream's)
> | > | >    configure.ac:
> | > | >    
> | > | >    dnl Library versioning (C:R:A == current:revision:age)
> | > | >    dnl See the libtool manual for an explanation of the numbers
> | > | >    dnl
> | > | >    dnl gsl-1.0    libgsl 0:0:0  libgslcblas 0:0:0
> | > | >    dnl gsl-1.1    libgsl 1:0:1  libgslcblas 0:0:0
> | > | >    dnl gsl-1.1.1  libgsl 2:0:2  libgslcblas 0:0:0
> | > | >    dnl gsl-1.2    libgsl 3:0:3  libgslcblas 0:0:0
> | > | >    dnl gsl-1.3    libgsl 4:0:4  libgslcblas 0:0:0
> | > | >    dnl gsl-1.4    libgsl 5:0:5  libgslcblas 0:0:0
> | > | >    dnl gsl-1.5    libgsl 6:0:6  libgslcblas 0:0:0
> | > | >    dnl gsl-1.6    libgsl 7:0:7  libgslcblas 0:0:0
> | > | >    dnl gsl-1.7    libgsl 8:0:8  libgslcblas 0:0:0
> | > | >    dnl gsl-1.8    libgsl 9:0:9  libgslcblas 0:0:0
> | > | >    dnl gsl-1.9    libgsl 10:0:10 libgslcblas 0:0:0 
> | > | >    dnl gsl-1.10   libgsl 10:0:10 (*) libgslcblas 0:0:0 
> | > | >    dnl gsl-1.11   libgsl 12:0:12  libgslcblas 0:0:0 
> | > | >    dnl gsl-1.12   libgsl 13:0:13  libgslcblas 0:0:0 
> | > | >    dnl gsl-1.13   libgsl 14:0:14  libgslcblas 0:0:0 
> | > | >    dnl gsl-1.14   libgsl 15:0:15  libgslcblas 0:0:0 
> | > | >    dnl gsl-1.15   libgsl 16:0:16  libgslcblas 0:0:0 
> | > | >    dnl gsl-1.16   libgsl 17:0:17  libgslcblas 0:0:0 
> | > | >    dnl gsl-2.0    libgsl 18:0:18  (**) libgslcblas 0:0:0 
> | > | >    dnl gsl-2.1    libgsl 19:0:0   libgslcblas 0:0:0 
> | > | >    dnl gsl-2.2    libgsl 20:0:1   libgslcblas 0:0:0 
> | > | >    dnl gsl-2.2.1  libgsl 21:0:2   libgslcblas 0:0:0 
> | > | >    dnl gsl-2.3    libgsl 22:0:3   libgslcblas 0:0:0 
> | > | >    dnl gsl-2.4    libgsl 23:0:0   libgslcblas 0:0:0 
> | > | >    dnl 
> | > | >    dnl (*) There was an error on this release.  Firstly, the 
> versioning
> | > | >    dnl numbers were not updated.  Secondly, 2 functions were removed, 
> but
> | > | >    dnl the age not reset--this should have been 11:0:0.  However these
> | > | >    dnl functions were not documented and are regarded as internal, so 
> we
> | > | >    dnl will assume 11:0:11.
> | > | >    dnl
> | > | >    dnl (**) There was an error on this release. Age should have been
> | > | >    dnl reset to 18:0:0
> | > | >    
> | > | >    I maitained this for close to 20 years, and we done (IIRC) ONE 
> soname change.
> | > | 
> | > | The list above only contains 3 ABI changes, of which one was "ignored"
> | > | by upstream.
> | > | 
> | > | The first one (ignored as detailed above):
> | > | > dnl gsl-1.9    libgsl 10:0:10 libgslcblas 0:0:0
> | > | > dnl gsl-1.10   libgsl 10:0:10 (*) libgslcblas 0:0:0
> | > | 
> | > | One here:
> | > | > dnl gsl-1.16   libgsl 17:0:17  libgslcblas 0:0:0
> | > | > dnl gsl-2.0    libgsl 18:0:18  (**) libgslcblas 0:0:0
> | > | > dnl gsl-2.1    libgsl 19:0:0   libgslcblas 0:0:0
> | > | 
> | > | And the current one we're talking about here:
> | > | > dnl gsl-2.3    libgsl 22:0:3   libgslcblas 0:0:0
> | > | > dnl gsl-2.4    libgsl 23:0:0   libgslcblas 0:0:0
> | > 
> | > Hm. Colour me confused.
> | > 
> | > Have I been reading this wrong all this time by reading _from left to 
> right_
> | > and refusing to force a new soname (and package name) on every release?
> | > 
> | > If the 'age reset to 0' is the actionable item, then I'd be up for it.  I
> | > could make a -3 release with a libgsl23 package keeping it at libgsl-dev.
> | > 
> | > I guess that's better than forcing a non-change.
> | 
> | Yes the "age reset to 0" is what causes ABI breakage and will cause an
> | SONAME change on Linux - you don't need to change the package name every
> | single release. I think renaming the package to libgsl23 (which will cause a
> | package transition) is the correct thing to do.
> 
> Thanks for the patient help -- really appreciate it.
> 
> I think I will create a libgsl23 tomorrow then, giving other a chance to
> chime in if need be.
> 
> One "technical" question: Is "causes ABI breakage" correct in the sense of
> instructing ld.so to balk at this?  Or more a "recommended to set to 0 to
> signal an ABI change" ?

Yeah the term I used probably isn't quite right.

If you don't set age to 0 but break the ABI, applications may crash at
any time (missing symbols will cause ld.so to fail, public struct
changes will cause segfaults etc). This is "ABI breakage".

If you do set age to 0 forcing an "ABI break" then the library name will
change. In theory you could then ship both the old and new libraries and
everything will work. After rebuilding everything with the new library,
you can safely remove the old one.

James

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to