0.9.4.0 changed the interface and didn't bump the SONAME

[yurivict]

Depending packages require to be patched now, for example https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252581

Please always bump the shared library's soname when breaking API changes are made:

lib/libusrsctp.so.1
lib/libusrsctp.so.1.0.0

In this case 1 should be changed to 2.

[Neustradamus]

@yurivict: Thanks a lot for your issues (on FreeBSD bugtracker and here), please read and comment here:

• New official release before Debian 11 freeze (needed for projects) #561

[tehnick]

Yes, this is unfortunate situation.

@tuexen How about adding a tiny fix (just bumping of soversion/soname) and making of new git tag 0.9.4.1 for them?

[Neustradamus]

@tehnick: I think that 1.0.0 or 1.0.0.0 will be better, like Fedora 31/32/33/34 have already 1.0.0 versions: https://src.fedoraproject.org/rpms/usrsctp:

• Fedora 34 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc34
• Fedora 33 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc33
• Fedora 32 usrsctp-1.0.0-0.1.20201017gitf4925bd.fc32

From:

• New official release before Debian 11 freeze (needed for projects) #561 (comment)

cc: @xvitaly.

Note: The API has changed: #561 (comment) + #561 (comment) + #318 + #439

[tuexen]

Yes, this is unfortunate situation.

@tuexen How about adding a tiny fix (just bumping of soversion/soname) and making of new git tag 0.9.4.1 for them?

Where is the soversion set in comparison to the version of the library? I guess for the autotools stuff, this sets the version of the library, and this sets the soversion.
@weinrank What are the corresponding entries for cmake?
@lgrahl What are the corresponding entries for meson?

We can bump the version 0.9.4.1 and to soversion to 2.0.0.

[tehnick]

I guess for the autotools stuff, this sets the version of the library, and this sets the soversion.

I am not sure that this is correct assumption regarding soversion. As far as I see, package libusrsctp in Debian is built using autotools. (Just find dh_auto_configure in a build log) But resulting SONAME looks like:

$ objdump -p /usr/lib/x86_64-linux-gnu/libusrsctp.so.1.0.0 | grep SONAME
  SONAME               libusrsctp.so.1

So real soversion is autotools based builds is 1 now.

What are the corresponding entries for cmake?

In cmake based builds library version and soversion are set by one string:

set_target_properties(usrsctp PROPERTIES SOVERSION 1 VERSION 1.0.0)

I do not know a situation with Meson build system, because I have never worked with it, but this string looks very suspicious to me. Please test that shared library built by it has the same SONAME libusrsctp.so.1 as builds by other build systems.

We can bump the version 0.9.4.1 and to soversion to 2.0.0.

I would recommend to use soversion 2 for version 0.9.4.1 instead, because current soversion is just 1.

Just a side note for @jonassmedegaard , not related to library:
Do I understand correctly that we will be able to use only version 0.9.4.0 in Debian Bullseye? Because after bumping of library soname binary package should be renamed to libusrsctp2 and this cannot be done now due to freeze of library transitions?

[xvitaly]

I will send a PR with fixes shortly.

[tehnick]

I do not know a situation with Meson build system

Hey! I have looked at packages in Fedora and I have found in build log that they are built using meson. And as we see in related compiler option: -Wl,-soname,libusrsctp.so.1. So everything is fine.

[xvitaly]

Meson does not support X.Y.Z.N versions:

../meson.build:188:4: ERROR: Invalid Shared library version "0.9.4.1". Must be of the form X.Y.Z where all three are numbers. Y and Z are optional.

[xvitaly]

Introduced a separate API/ABI version fields for shared library version:

Meson:

# Shared library API and ABI versions
soversion_full = '2.0.0'
soversion_short = '2'

Cmake:

# Shared library API and ABI versions
set(SOVERSION_FULL "2.0.0")
set(SOVERSION_SHORT "2")

Will try to do the same for the automake.

[xvitaly]

I think it will be better to use the full SOVERSION to be unified with all supported build systems. I will update my PR shortly.

Now all build systems produces the same result.

Cmake:

$ ls -l
lrwxrwxrwx. 1 vitaly vitaly      15 Jan 13 14:01 libusrsctp.so -> libusrsctp.so.2
lrwxrwxrwx. 1 vitaly vitaly      19 Jan 13 14:01 libusrsctp.so.2 -> libusrsctp.so.2.0.0
-rwxrwxr-x. 1 vitaly vitaly 1801360 Jan 13 14:01 libusrsctp.so.2.0.0

$ objdump -p libusrsctp.so.2.0.0 | grep SONAME
  SONAME               libusrsctp.so.2

Meson:

$ ls -l
lrwxrwxrwx. 1 vitaly vitaly      15 Jan 13 14:02 libusrsctp.so -> libusrsctp.so.2
lrwxrwxrwx. 1 vitaly vitaly      19 Jan 13 14:02 libusrsctp.so.2 -> libusrsctp.so.2.0.0
-rwxrwxr-x. 1 vitaly vitaly 1731888 Jan 13 14:03 libusrsctp.so.2.0.0

$ objdump -p libusrsctp.so.2.0.0 | grep SONAME
  SONAME               libusrsctp.so.2

Automake:

$ ls -l
lrwxrwxrwx. 1 vitaly vitaly      19 Jan 13 14:04 libusrsctp.so -> libusrsctp.so.2.0.0
lrwxrwxrwx. 1 vitaly vitaly      19 Jan 13 14:04 libusrsctp.so.2 -> libusrsctp.so.2.0.0
-rwxr-xr-x. 1 vitaly vitaly 1798720 Jan 13 14:04 libusrsctp.so.2.0.0

$ objdump -p libusrsctp.so.2.0.0 | grep SONAME
  SONAME               libusrsctp.so.2

LGTM now.

[jonassmedegaard]

I guess for the autotools stuff, this sets the version of the library, and this sets the soversion.

Almost correct.

SONAME is not the value defined in the Makefile but is computed from those 3 components.

Probably best documentation of libtool versioning (better than official documentation) is this: https://autotools.io/libtool/version.html

I am not sure that this is correct assumption regarding soversion. As far as I see, package libusrsctp in Debian is built using autotools. (Just find dh_auto_configure in a build log) But resulting SONAME looks like:

$ objdump -p /usr/lib/x86_64-linux-gnu/libusrsctp.so.1.0.0 | grep SONAME
  SONAME               libusrsctp.so.1

So real soversion is autotools based builds is 1 now.

Correct.

We can bump the version 0.9.4.1 and to soversion to 2.0.0.

I would recommend to use soversion 2 for version 0.9.4.1 instead, because current soversion is just 1.

I would recommend to read the libtool versioning documentation referenced above before deciding which should be the nex SONAME.

Just a side note for @jonassmedegaard , not related to library:
Do I understand correctly that we will be able to use only version 0.9.4.0 in Debian Bullseye? Because after bumping of library soname binary package should be renamed to libusrsctp2 and this cannot be done now due to freeze of library transitions?

Correct: Yesterday was the deadline for introducing major library changes (and "introducing" involves a screening by the Debian ftpmaster team which can take days or weeks, so even if uploaded yesterday it was unlikely to make it in time).

That said, the damage is already done: the breaking change tracked in this issue was introduced 5 months ago and is included in Debian.
Therefore the ideal, as I see it, would be that this project as soon as possible issue a release with SONAME bumped, and that I try make an exception to have it included in Debian despite having passed the deadline (there is currently only one package in Debian depending on it, which helps making such exception).

[xvitaly]

@tehnick @jonassmedegaard Please check PR #565. It should fix all of these issues.

[jonassmedegaard]

otherwise - if Debian won't accept an exception to sneak in a new major release of libusrsctp, then it simply means what was known already: That SONAME 1 is an unstable SONAME that can mean multiple things, because it stayed the same across multiple years with (unfortunately) at least one breakage.