Bug #3175
closedPackaging: Upgrading libosmocore impossibel due to dpkg error overwriting libosmoctrl.so.0
90%
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
Updated by laforge over 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}),
Updated by laforge over 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:- return to "libosmoctrl0" package name (and the dependencies)
- 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?
Updated by laforge over 6 years ago
- Related to Bug #3176: osmocom debian packages are not install / upgrade tested added
Updated by keith over 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..
Updated by pespin over 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.
Updated by pespin over 6 years ago
- Related to Feature #3228: build-system: check match between debian package names and shared object files added
Updated by pespin over 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.
Updated by laforge over 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.