Project

General

Profile

Actions

Bug #3175

closed

Packaging: Upgrading libosmocore impossibel due to dpkg error overwriting libosmoctrl.so.0

Added by keith almost 6 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
libosmoctrl
Target version:
-
Start date:
04/16/2018
Due date:
% Done:

90%

Spec Reference:

Description

I built libosmocore packages from current master and added to my private test repo:

When apt-get install'ing these upgrades, the upgrade fails and the package manager gets into a broken state, beginning with refusing to install libosmoctrl1, because:

Unpacking libosmoctrl1 (from .../libosmoctrl1_0.10.2-0rhizo1_amd64.deb) ...
dpkg: error processing /var/cache/apt/archives/libosmoctrl1_0.10.2-0rhizo1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libosmoctrl.so.0', which is also in package libosmoctrl0 0.9.6-0rhizo2

Related issues

Related to Cellular Network Infrastructure - Bug #3176: osmocom debian packages are not install / upgrade testedResolvedosmith04/16/2018

Actions
Related to Cellular Network Infrastructure - Feature #3228: build-system: check match between debian package names and shared object filesResolvedpespin05/03/2018

Actions
Actions #1

Updated by laforge almost 6 years ago

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}),

Actions #2

Updated by laforge almost 6 years ago

  • Category set to libosmoctrl
  • Assignee set to pespin
  • % Done changed from 0 to 10

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?

We have two choices, AFAICT:
  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?

Actions #3

Updated by laforge almost 6 years ago

  • Related to Bug #3176: osmocom debian packages are not install / upgrade tested added
Actions #4

Updated by keith almost 6 years ago

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..

Actions #5

Updated by pespin almost 6 years ago

  • Status changed from New to In Progress

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.

Actions #6

Updated by pespin almost 6 years ago

  • Related to Feature #3228: build-system: check match between debian package names and shared object files added
Actions #7

Updated by pespin almost 6 years ago

  • Status changed from In Progress to Feedback
  • Assignee changed from pespin to keith
  • % Done changed from 10 to 90

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.

Actions #8

Updated by laforge almost 5 years ago

  • Status changed from Feedback to Resolved

considering resolved after we assumed that it's fixed a year ago and not further feedback was provided.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)