Osmocom Libraries » libosmocore

This appears to be broken since 0.10.0 where we do:

-         libosmocore8 (= ${binary:Version}),
-         libosmogb4 (= ${binary:Version}),
-         libosmogsm7 (= ${binary:Version}),
-         libosmovty3 (= ${binary:Version}),
-         libosmoctrl0 (= ${binary:Version}),
+         libosmocore9 (= ${binary:Version}),
+         libosmogb5 (= ${binary:Version}),
+         libosmogsm8 (= ${binary:Version}),
+         libosmovty4 (= ${binary:Version}),
+         libosmoctrl1 (= ${binary:Version}),

so we incresed the debian package name from libosmoctrl0 to libosmoctrl1 at the time of the 0.10.0 release. However, the library name is still libosmoctrl.0, most likely because LIBVERSION=1:0:1, i.e. the "age" is set to 1, meaning the library supports both the "0" as well as the "1" API version?

1. return to "libosmoctrl0" package name (and the dependencies)
2. do whatever it takes to produce libosmoctrl.so.1 (probably remove the "age")?

I don't know enough about how debian packaging deals with / interacts with libversions. From the library point of view it makes sense to have the 1:0:1 i.e. API 0 + 1 compatible. But how does the package manager deal with that?

keith: Also, why is it not simply replacing libosmoctrl0 with libosmoctrl1? do you have any packages installed depending on libosmoctrl0?

laforge wrote:

keith: Also, why is it not simply replacing libosmoctrl0 with libosmoctrl1? do you have any packages installed depending on libosmoctrl0?

Well, yes, pre-ugrading, at least osmocom-nitb depends on libosmoctrl0, of course.
It is true that I added the newer libosmocore packages to my repo and attempted upgrade of libosmocore before also adding the updated osmocom-nitb package to the repo, so maybe having the updated osmocom-nitb package depending on libosmoctrl1 would allow dpkg to replace libosmoctrl0 with libosmoctrl1.

I don't have enough dpkg-foo to know. I'll roll back to the previous package state and complete the repo and test..

I did some tests building libosmoctrl in OBS after upgrading the LIBVERSION (-version_info) for libosmoctrl:

src/ctrl/Makefile.am
4:LIBVERSION=2:0:2
13:libosmoctrl_la_LDFLAGS = $(LTLDFLAGS_OSMOCTRL) -version-info $(LIBVERSION) -no-undefined

Initial values before my changes was: LIBVERSION=1:0:1

I also moved libosmoctrl1.install to libosmoctrl2.install (and updated control file accordingly).

When building the deb package libosmoctrl2.deb the following files: libosmoctrl.so.0 -> libosmocotrl.so.0.2.0

So it seems increasing the age affects too the debian package, contrary to what we had written in https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release#Library-release

An explanation can be found here: https://github.com/haskell/cabal/issues/4052#issuecomment-258044949

After some more googling, it seems that asking for a libtool-style current[:revision[:age]] style specification is the sanest thing to do. The field could then be called version-info, the name in libtool. Perhaps library-version-info would make it even less ambiguous.

On linux, current:revision:age gets translated into version number major.age.revision, where major=current-age, reflecting the fact that ABIs can be backwards compatible. And then the SONAME is libfoo.so.major.

I'll update the wiki page and update the debian packages accordingly following this explanation.

Should be fixed by libosmocore 93288d76daac66e5c47905476f7632c4b441ea4c, which is already in the newly generated version and as a result should be shortly fixed in both latest and nightly.