libArcus icon indicating copy to clipboard operation
libArcus copied to clipboard

SOVERSION / VERSION / Cura version mismatch

Open onitake opened this issue 8 years ago • 4 comments

I ran into this problem while attempting to package Cura up for Debian: There seems to be a general disagreement over which versioning scheme to use for libArcus.

  • The "release" uses the same scheme as Cura (ex. 2.3.0)
  • The library version is currently 1.1.0
  • The SOVERSION (i.e. API level) is 3

While technically not an issue, it is highly confusing and causes lintian to throw a tantrum. Silencing it is an option, but I'd rather have an official opinion why Arcus doesn't use a more consistent versioning scheme.

Even better, it would be nice if the three versions would match up. I understand that this will most likely introduce a discrepancy between Cura and libArcus, but I don't think it will be a major problem. One can always require a specific library version, if necessary.

onitake avatar Feb 15 '17 09:02 onitake

The versions are mismatched because I have not yet finished decoupling Arcus from Cura's release cycle. The correct version here is 1.1.0 (or maybe 1.1.1) to indicate it is a separate release. I just have not yet had the time to make it a proper separate release.

awhiemstra avatar Feb 15 '17 11:02 awhiemstra

Ok, that's good to hear.

In this case, I would like to tag the Debian package as follows:

  • Package: libarcus-1.1.0-1
  • Library: libArcus.so.1.1.0
  • SOVERSION: 1

Would this break compatibility with older library versions?

An alternative, taking API changes into account, could be:

  • Package: libarcus3-1.1.0-1
  • Library: libArcus.so.1.1.0
  • SOVERSION: 3

onitake avatar Mar 03 '17 18:03 onitake

Hmm, why does the SOVERSION need to be 1? On the other hand, if it is a requirement for Debian packages I am fine with changing the soversion to 1.

awhiemstra avatar Mar 06 '17 09:03 awhiemstra

Well, the SOVERSION is something like the API level of a shared library. It is normally only incremented when breaking changes are introduced. I don't know how stable the API of Arcus has been until now, so it's up to you to decide which version is correct.

Setting it to 1 would synchronize it with the library version, but having different versioning is perfectly ok too. The important thing here is consistency, so a package doesn't need changes every time a new upstream release is made.

The most well-known example for non-synchronised versioning is probably the GNU C library: Its API level (and thus SOVERSION) is 6, the resulting SONAME is libc.so.6, but the actual version is something like 2.24. This results in the Debian package libc6, version 2.24-9 for example. Programs are linked against the SONAME:

$ ldd /bin/bash
...
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 ...
...

onitake avatar Mar 06 '17 18:03 onitake