SOVERSION bumps and package names in Debian

21 views
Skip to first unread message

Rafael Laboissière

unread,
Dec 19, 2021, 4:56:57 AM12/19/21
to MathGL
Hi,

I am a member of the Debian Science Team and I got involved in the development of the Debian packages for MathGL. The latest version of MathGL produces the following binary packages in Debian:

libmgl-data
libmgl-dev
libmgl-fltk7.6.0
libmgl-glut7.6.0
libmgl-mpi7.6.0
libmgl-qt5-7.6.0
libmgl-wnd7.6.0
libmgl-wx7.6.0
libmgl7.6.0
mathgl
python3-mathgl
udav

As you can see in the list above, the SOVERSION of the libraries ends up in the package names. This is not the usual way packaging of shared libraries is done in Debian. Usually, the package name contains only the major number of the SOVERSION, so that we would have libmgl7 instead of libmgl7.6.0.

In the specific case of MathGL, maintaining the Debian packages is a bit painful, because we have to add update the Replaces and Conflicts relationships in debian/control at each SOVERSION bump.

A simple-minded patch as the one at the end of this message could mitigate the problem, by creating libraries with the appropriate SONAME. However, there is another issue with the versioning of the shared libraries in MathGL. Even though there are several individual libraries, there is a single SOVERSION for them all. IMHO, each library should have its specific versioning scheme. As an example, look at how PLplot keeps separate SOVERSION/VERSION for each individual library.

You might implement something similar in MathGL.

Best regards,

Rafael Laboissière

===========================================================

--- mathgl-2.5.orig/CMakeLists.txt
+++ mathgl-2.5/CMakeLists.txt
@@ -26,7 +26,8 @@ set(MathGL_VERSION_MAJOR 2)
 set(MathGL_VERSION_MINOR 5)
 set(MathGL_PATCH_VERSION 0)
 set(MathGL_VERSION ${MathGL_VERSION_MAJOR}.${MathGL_VERSION_MINOR}.${MathGL_PATCH_VERSION})
-set(MathGL_SOVERSION 7.6.0)
+set(MathGL_SOVERSION 7)
+set(MathGL_VERSION 7.6.0)
 string(TIMESTAMP MathGL_DATE UTC)
 
 if(CMAKE_BUILD_TYPE STREQUAL "Debug")
@@ -80,6 +81,7 @@ function(mgl_add_lib mgl_tmp_lib)
        add_library(${mgllib} SHARED ${mgl_src_lst})
        add_library(${mgllib}-static STATIC ${mgl_src_lst})
        set_target_properties(${mgllib} PROPERTIES SOVERSION ${MathGL_SOVERSION})
+       set_target_properties(${mgllib} PROPERTIES VERSION ${MathGL_VERSION})
        set_target_properties(${mgllib} PROPERTIES DEFINE_SYMBOL "mgl_EXPORTS")
        set_target_properties(${mgllib} PROPERTIES C_VISIBILITY_PRESET hidden)
        set_target_properties(${mgllib} PROPERTIES CXX_VISIBILITY_PRESET hidden)

Alexey Balakin

unread,
Dec 21, 2021, 3:09:22 PM12/21/21
to mat...@googlegroups.com
Hi,

I'm a bit confused by this problem. As I remember SOVERSION denote the incompatible changes (major soversion) and adding new functions (minor soversion). The last number denote patches or code improvement (useless for me). The both numbers (major and minor soversion) are important in general case. So, yours variant is not so good. I see only three ways for a solution:

1. Replace the "set(MathGL_SOVERSION 7.6.0)" by "set(MathGL_SOVERSION 7.6)". This is minimal changes and just hide ".0" in SOVERSION, which is useless in any case. Some Debian packages use such way.

2. Rename "mgl" by "mgl2" (i.e. libmgl to libmgl2 and so on) and replace SOVERSION by its actual version (i.e. "set(MathGL_SOVERSION 7.6.0)" by "set(MathGL_SOVERSION 2.5.0)"). But I'm afraid that such change will cause a lot of compatibility problems for users.

3. Change MathGL version numbering, i.e. release "dummy" version 7.6 (or even 8.0) instead of 2.5 (the current one) and keep SOVERSION rules for further releases. Probably this is most correct way, but this is very surprising version change and should be done in a very unusual day (like, 1 January or 1 April ;-) ).

So, the question is following. Is it enough for you if I go to way 1? or I should choose the way 3 and you will wait a 1-2 weeks?

19.12.2021 01:21, Rafael Laboissière пишет:
--
You received this message because you are subscribed to the Google Groups "MathGL" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mathgl+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mathgl/d73c0853-2808-4f45-9cfa-742f26a41615n%40googlegroups.com.


-- 
Kind regards,
Alexey Balakin

Rafael Laboissière

unread,
Dec 22, 2021, 3:39:13 AM12/22/21
to mat...@googlegroups.com
Hi,

As far as I understand, the usual scheme for versioning shared libraries
with three numbers (MAJOR.MINOR.MICRO) is as follows:

– If there are backward incompatible API/ABI changes, increase MACRO and set MINOR and MICRO to zero.
– If the API is changed but the library remains backward compatible (for instance, only new functions have been added), then keep MAJOR, increase MINOR and set MICRO to zero.
– If the code changed (for instance, performance improvements), but there are no changes in the API, then keep MAJOR and MINOR and increase MICRO.

At any rate, the version of the software (in your case currently 2.5) can
evolve separately from the SO versions, as you have done in the past,
even though you had a single SOVERSION for all libraries.

That said, there is no need to immediately release a new version of
MathGL just to “fix” the SO numbering. You can start implementing the new
versioning system when you will be ready for a new release.

I would suggest that you keep the VERSION of the libraries as they are
now (7.6.0) and upgrade just what is necessary. Let us work out a
hypothetical case. Suppose that, in the next version of MathGL (say,
version 2.6), you:

– change the API of libmgl-glut,
– add a new function to libmgl-fltk, and
– change the code of libmgl-wx (without changes in the API/ABI).

Then, you should have:

libmgl
VERSION = 7.6.0
SOVERSION = 7

libmgl-mpi
VERSION = 7.6.0
SOVERSION = 7

libmgl-wnd
VERSION = 7.6.0
SOVERSION = 7

libmgl-glut
VERSION = 8.0.0
SOVERSION = 8

libmgl-qt5
VERSION = 7.6.0
SOVERSION = 7

libmgl-fltk
VERSION = 7.7.0
SOVERSION = 7

libmgl-wx
VERSION = 7.6.1
SOVERSION = 7

It is important that you set both the VERSION and SOVERSION properties
for the libraries in CMakeList.txt. In this case, the new Debian packages
will be named like this:

libmgl7
libmgl-mpi7
libmgl-wnd7
libmgl-glut8
libmgl-qt5-7
libmgl-fltk7
libmgl-wx7

Best,

Rafael

* Alexey Balakin <mathgl....@gmail.com> [2021-12-21 23:09]:
>> <https://packages.debian.org/source/sid/mathgl>. The latest version
>> of MathGL produces the following binary packages in Debian:
>>
>> libmgl-data
>> libmgl-dev
>> libmgl-fltk7.6.0
>> libmgl-glut7.6.0
>> libmgl-mpi7.6.0
>> libmgl-qt5-7.6.0
>> libmgl-wnd7.6.0
>> libmgl-wx7.6.0
>> libmgl7.6.0
>> mathgl
>> python3-mathgl
>> udav
>>
>> As you can see in the list above, the SOVERSION of the libraries
>> ends up in the package names. This is not the usual way packaging of
>> shared libraries is done in Debian. Usually, the package name
>> contains only the major number of the SOVERSION, so that we would
>> have libmgl7 instead of libmgl7.6.0.
>>
>> In the specific case of MathGL, maintaining the Debian packages is a
>> bit painful, because we have to add update the Replaces and
>> Conflicts relationships in debian/control <https://salsa.debian.org/science-team/mathgl/-/blob/master/debian/control> at
>> each SOVERSION bump.
>>
>> A simple-minded patch as the one at the end of this message could
>> mitigate the problem, by creating libraries with the appropriate
>> SONAME. However, there is another issue with the versioning of the
>> shared libraries in MathGL. Even though there are several individual
>> libraries, there is a single SOVERSION for them all. IMHO, each
>> library should have its specific versioning scheme. As an example,
>> look at how PLplot keeps <https://sourceforge.net/p/plplot/plplot/ci/master/tree/cmake/modules/plplot_version.cmake> separate
>> To view this discussion on the web visit https://groups.google.com/d/msgid/mathgl/d73c0853-2808-4f45-9cfa-742f26a41615n%40googlegroups.com <https://groups.google.com/d/msgid/mathgl/d73c0853-2808-4f45-9cfa-742f26a41615n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
> --
> Kind regards,
> Alexey Balakin
>
> --
> You received this message because you are subscribed to the Google Groups "MathGL" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mathgl+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mathgl/3ebfe675-f36a-5a44-ad0a-435339b07bba%40gmail.com.

Alexey Balakin

unread,
Dec 22, 2021, 9:04:19 AM12/22/21
to mat...@googlegroups.com
Ok, I'll make new release v.8.0 and put into it all changes which I plan
to do (remove Qt4 support, change C-functions for colorbars, and so on).
I hope I'll do it before 1 January.

22.12.2021 11:39, Rafael Laboissière пишет:
Reply all
Reply to author
Forward
0 new messages