Project

General

Profile

Actions

Bug #2640

closed

Debian nightly packages should conflict with debian latest packages

Added by laforge over 6 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
11/15/2017
Due date:
% Done:

100%

Spec Reference:

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.

Actions #1

Updated by laforge over 5 years ago

  • Assignee changed from 4368 to lynxis
Actions #2

Updated by laforge over 5 years ago

  • Assignee changed from lynxis to osmith
Actions #3

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 :/

Actions #4

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:

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?

Actions #5

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!

Actions #6

Updated by osmith almost 5 years ago

I'm planning to do this after #3899, so there are no conflicts.

Actions #7

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.
Actions #8

Updated by osmith almost 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)