Bug #2640
closed
Debian nightly packages should conflict with debian latest packages
Added by laforge over 6 years ago.
Updated almost 5 years ago.
Description
If a user first uses packages from the network:osmocom:nightly feed, and then switches to the network:osmocom:latest feed, we would ideally want a situation where the "nightly" packages conflict with the "latest" ones, as the version numbers and dependencies of "nightly" will not properly work out. This is due to the fact that the source code version numbers are not incremented/tagged on a daily/nightly basis, but only once we tag a new version (which will then create new "latest" packages).
Yes, we know, a skilled user will understand there's a problem and will make sure to properly uninstall any "nightly" packages before installing "latest".
The same should be true for "nightly" vs. the official packages in upstream Debian/Ubuntu.
It's not yet clear how we can achieve this, but it would be great to have it in place. When "latest" or "official" packages are install, all "nightly" packages should be removed due to a conflict in dpkg packaging information.
- Assignee changed from 4368 to lynxis
- Assignee changed from lynxis to osmith
ping? This sounds like a rather quick/small task to investigate if dpkg offers something like this, and it's sad to see it hanging here for 7 months :/
Sorry for the delay on this task.
I did some research, and could not find any sort of best practices, regarding how to make packages from one repository conflict with another repository (found that funny wiki page though).
So I would approach this as follows:
This should generate a nice error message, something along the lines of osmocom-latest is conflicting with osmocom-nightly.
I would add the dependency to osmocom-latest/-nightly to the debian/control
file right before we generate the source packages and submit them to OBS, in osmo-ci.git's scripts/osmocom-{nightly,latest}-packages.sh.
laforge, what do you think about this approach?
On Thu, May 09, 2019 at 11:19:19AM +0000, osmith [REDMINE] wrote:
laforge, what do you think about this approach?
sounds great, thanks!
I'm planning to do this after #3899, so there are no conflicts.
- Status changed from New to In Progress
- % Done changed from 0 to 90
Patch submitted: https://gerrit.osmocom.org/c/osmo-ci/+/14490
Everything tested with my own OBS namespace. I've built all packages, then added both latest and nightly to my local debian installation.
The conflict between nightly and latest packages is working, apt will not install packages from nightly together with packages from latest and vice versa.
$ sudo apt install libosmocore=1.1.0.68.a08e
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libosmocodec0 libosmocoding0 libosmocore12 libosmoctrl0 libosmogb9 libosmogsm12 libosmosim0 libosmovty4 osmocom-nightly
... (install goes through)
$ sudo apt install osmo-hlr=1.0.0
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
osmo-hlr : Depends: osmocom-latest but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
Also available in: Atom
PDF