[Pkg-xmpp-devel] libsignal-protocol-c transition? (dino-im, profanity, psi-plus)

[Boris Pek]

Hi,

> between 2.3.1 and 2.3.2 libsignal-protocol-c made an API change
> (signature change of load_session_func() in
> https://github.com/signalapp/libsignal-protocol-c/commit/6a9a83b6f31d4015c5b4863b509521723e5ef9b3).
> Unfortunately, the major number and soname have not been
> increased.

Yep, and developers just closed related issue [1].

But there are even more problems with this library.

For example, developers forgot to bump program version in sources before new
git tag [2]. Three days after that they have merged PR [3] with version
increment and just updated git tag [4] without any notifications.

It looks like library developers never heard that in many packaging systems
(in different GNU/Linux distros, FreeBSD ports, Homebrew for macOS, MXE and
MINGW-packages for MS Windows, HaikuPorts, etc.) checksums are used to control
the correctness of tarballs downloaded from upstream.

We may only hope that such situations will not be repeated.

[1] https://github.com/signalapp/libsignal-protocol-c/issues/112
[2] https://github.com/signalapp/libsignal-protocol-c/issues/107
[3] https://github.com/signalapp/libsignal-protocol-c/pull/110
[4] https://github.com/signalapp/libsignal-protocol-c/releases/tag/v2.3.2

> The library has only three dependencies, dino-im, profanity, and
> psi-plus, which must be compatible to the library version.

psi-plus supports both versions. (There is ugly hack for that in OMEMO plugin
sources [5][6][7] because there are no defines with library version in its
header files which may be used at compile time.) From maintainers point of
view this means we may use both binNMU or source upload with any version of
Psi+ after updating of package with libsignal-protocol-c library.

As for dino-im the situation is a bit different: developers support build only
with latest version of libsignal-protocol-c [8], so upload of new version of
dino-im will be needed (with updated version in build dependencies).

As for profanity I have no idea about situation with it.

Also in the future we will have fourth package dependent from this library:
I am going to upload NEW package psi-plugins which includes the same OMEMO
plugin as one from psi-plus-plugins package. But this will be far far later
than we will update libsignal-protocol-c. So this is just as a side note.

[5] https://github.com/psi-plus/psi-plus-snapshots/blob/1.4.554/src/plugins/generic/omemoplugin/CMakeLists.txt#L52
[6] https://github.com/psi-plus/psi-plus-snapshots/blob/1.4.554/src/plugins/generic/omemoplugin/omemoplugin.pro#L16
[7] https://github.com/psi-plus/psi-plus-snapshots/blob/1.4.554/src/plugins/generic/omemoplugin/config.tests/oldSignal/main.cpp
[8] https://github.com/dino/dino/commit/7012023d

> I'm not sure, how to solve the problem, but can imagine:
>
> A. We can just increase the major version number to 3 and ask
>    upstream to skip the 3 and jump directly to 4 with the next
>    release. (Not sure, whether they will do that.)

I would be positively surprised if they will do this for us. =)

If seriously, please do not mix library version and its SONAME: there is no
need to keep them in sync.

Of course it is a convenient practice when ABI "version" is a part of library
version. For example:
"<major part of version>"
or
"<major part of version>.<minor part of version>".

But in actively developed libraries with frequent changes in ABI we may often
see, for example, ABI "version" 76 for library version 1.2.3 or ABI "version"
1.2.3 which matches library version precisely.

For updating the package with library we need only two things:
1) SONAME should differ
2) SONAME should be bigger in new version of library

So we may choose any SONAME which we like:
* libsignal-protocol-c.so.2.1
* libsignal-protocol-c.so.2.3
* libsignal-protocol-c.so.2.3.2
* etc.

The name of binary package will reflect that change accordingly:
* libsignal-protocol-c2.1
* libsignal-protocol-c2.3
* libsignal-protocol-c2.3.2
* etc.

> B. We can add minor and micro number to the library symlink,
>    so that applications link against the exact version.

Yes, this would be the most obvious choice for us. I was going to use full
library version in its SONAME (libsignal-protocol-c.so.2.3.2).

>    (No idea how to do that exactly with cmake.)

It is trivial:

Find in src/CMakeLists.txt:

	set_target_properties(signal-protocol-c PROPERTIES
		VERSION ${SIGNAL_PROTOCOL_C_VERSION}
		SOVERSION ${SIGNAL_PROTOCOL_C_VERSION_MAJOR}
	)

and change it to:

	set_target_properties(signal-protocol-c PROPERTIES
		VERSION ${SIGNAL_PROTOCOL_C_VERSION}
		SOVERSION ${SIGNAL_PROTOCOL_C_VERSION}
	)

> C. We can version 2.3.2 let conflict with the current versions
>    of the three dependencies and let those depend on the newer
>    version. (No need to go through the new queue.)

I would strongly suggest you do not do such things.

> Any other ideas? Comments?
>
> Until buster release, all that would happen in experimental, of course.

I thought to update libsignal-protocol-c package in experimental myself few
months ago, but still have not found time for this as you see. So please go
ahead. =)

Best regards,
Boris