Project

General

Profile

Bug #2640

Debian nightly packages should conflict with debian latest packages

Added by laforge over 1 year ago. Updated 13 days ago.

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

0%

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.

History

#1 Updated by laforge 11 months ago

  • Assignee changed from sysmocom to lynxis

#2 Updated by laforge 8 months ago

  • Assignee changed from lynxis to osmith

#3 Updated by laforge 14 days 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 :/

#4 Updated by osmith 13 days 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?

#5 Updated by laforge 13 days 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!

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)