Bug #2640
closedDebian nightly packages should conflict with debian latest packages
100%
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.
Updated by laforge almost 5 years ago
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 :/
Updated by osmith almost 5 years ago
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:- create one
osmocom-latest
and oneosmocom-nightly
dummy package, which are conflicting with each other (see https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts) - make all packages from latest depend on osmocom-latest, and all from nightly on osmocom-nightly
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?
Updated by laforge almost 5 years ago
On Thu, May 09, 2019 at 11:19:19AM +0000, osmith [REDMINE] wrote:
laforge, what do you think about this approach?
sounds great, thanks!
Updated by osmith almost 5 years ago
I'm planning to do this after #3899, so there are no conflicts.
Updated by osmith almost 5 years ago
- 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.
Updated by osmith almost 5 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100