Bug #3175
Packaging: 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
History
#1 Updated by laforge over 1 year 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}),
#2 Updated by laforge over 1 year 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?
#3 Updated by laforge over 1 year ago
- Related to Bug #3176: osmocom debian packages are not install / upgrade tested added
#4 Updated by keith over 1 year 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..
#5 Updated by pespin over 1 year 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.
#6 Updated by pespin over 1 year ago
- Related to Feature #3228: build-system: check match between debian package names and shared object files added
#7 Updated by pespin over 1 year 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.