Bug #3542
closed
Conflicting Debian packages: soapysdr0.5-module-lms7 and soapysdr0.6-module-lms7
Added by osmith over 5 years ago.
Updated over 5 years ago.
Description
During the implementation of #3176 I have discovered the following conflict when installing both packages:
Unpacking soapysdr0.5-2-module-lms7:amd64 (16.12.0+dfsg-1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-MovoKD/351-soapysdr0.5-2-module-lms7_16.12.0+dfsg-1_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so',
which is also in package soapysdr0.6-module-lms7:amd64 18.06.0-1
Note that the conflicting file has modules0.5-2 in the path in both the 0.5 and the 0.6 version. My guess is, that in the 0.6 version, this path should be modules0.6-...?
- Project changed from Cellular Network Infrastructure to SDR (Software Defined Radio)
- Blocks Bug #3176: osmocom debian packages are not install / upgrade tested added
I could not set this as a subtask of #3176 after creating the issue, probably because I don't have the rights in the SDR project. So I set it as blocker for the other issue, now they are linked together that way.
On Mon, Sep 10, 2018 at 02:05:43PM +0000, osmith [REDMINE] wrote:
I could not set this as a subtask of #3176 after creating the issue, probably because I don't have the rights in the SDR project. So I set it as blocker for the other issue, now they are linked together that way.
I don't think the redmine UI can do this. If you find some documentation, I'd be interested.
The only way how I have so far created subtasks is directly from the master issue, never by
later somehow attaching any other tickets.
about subtasks, I used to use them a lot, but the complex relations between them often made me regret that. These days all I do is just set "Related to".
- Status changed from New to Feedback
- Assignee set to osmith
Hmm, are we really packaging soapysdr from the Osmocom opensuse builds?
Are the differing soapy versions dependencies pulled in by Osmo packages?
About the modules of 0.5 and 0.6 conflicting, I'm not sure that this is related, but the LIBVERSION markers of .so files does not at all correspond to major.minor.patch software version tags.
This modules-0.5-2 looks like it isn't related to LIBVERSION either. Not sure what to make of this.
- Related to Bug #3540: Conflicting Debian packages: osmocom-bsc-sccplite and osmo-bsc-mgcp added
neels wrote:
Hmm, are we really packaging soapysdr from the Osmocom opensuse builds?
This is a good question. We have the following packages in the OBS repo (directory listing), as found by aptitude:
soapysdr-module-lms7
soapysdr0.6-module-lms7
soapysdr0.6-module-lms7-dbgsym
So no soapysdr0.5 there.
Are the differing soapy versions dependencies pulled in by Osmo packages?
Yes, they are. I'm figuring out where they come from. What I can tell so far is, that they still get pulled in, even after blacklisting packages coming from the obsolete openbsc.git.
EDIT: It might also be that soapysdr-module-lms7 pulls in the 0.5 package for some reason.
On Tue, Sep 11, 2018 at 07:01:59PM +0000, neels [REDMINE] wrote:
Hmm, are we really packaging soapysdr from the Osmocom opensuse builds?
we used to do, but now that we have osmo-trx-lms, we should deprecate that.
we used to do, but now that we have osmo-trx-lms, we should deprecate that.
That was a very useful clue! I've created a blacklist.txt for the cronjob with packages from the repository, that it will not try to install (originally to blacklist all openbsc.git derived packages). Now I've added the following packages, and the apt install runs through successfully!
# SoapySDR is not used anymore (see OS#3542)
soapysdr-module-lms7
soapysdr0.6-module-lms7
soapysdr0.6-module-lms7-dbgsym
This issue can now be closed (I don't get the UI to change the status here, probably because of missing rights).
I am not really sure where the soapysdr packages come from (they don't seem to be in osmocom-latest-packages.sh). If somebody could give me a pointer, I could look into removing the binary soapysdr packages from the Debian package repository if that is desired.
- Blocks deleted (Bug #3176: osmocom debian packages are not install / upgrade tested)
- Project changed from SDR (Software Defined Radio) to OsmoTRX
This is due to the fact that #3542 is a different osmocom sub-project.
OsmoSDR and/or its child projects rtl-sdr, gr-osmosdr, osmo-fl2k, gr-gsm
are all projects in which sysmocom is not involved, and where sysmocom
developers do not automatically get 'developer' privileges.
https://osmocom.org/projects/sdr will show you that the sysmocom
developers / employees are only listed in the 'Reporters' category.
Should sysmocom get involved in related projects, we could change that,
but I think in general it would be awkward to those projects and their
maintainers if employee status at sysmocm would automatically introduce
some role there.
I think the key problem is that this particular issue #3542 was filed in
the "Osmocom SDR" project. Sure, it affects SDR hardware or drivers,
but not the Osmocom SDR software projects, which I've listed above.
Sorry for the confusion :).
I'm moving it now.
- Status changed from Feedback to Rejected
- Related to Bug #3809: Osmocom-Debian-install-test fails since February 9 added
Also available in: Atom
PDF
