Project

General

Profile

Bug #5135

OBS nightly package upgrading breaks if commit did not change

Added by osmith 16 days ago. Updated 11 days ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
Start date:
04/27/2021
Due date:
% Done:

100%

Spec Reference:

Description

Nightly packages are built every night, even if their source did not change. All nightly packages depend on a "conflict package" osmocom-nightly with the build date set as version.

However, if the source does not change, the resulting version of a package does not change either.

If the package is already installed and the user tries to upgrade it, the package manager assumes that the installed package does not need to be upgraded as the version is the same.

This results in breakage if other packages do have different versions, and want to pull in a new version of osmocom-nightly, but at least one package has the same version and still depends on the old osmocom-nightly.

Workaround: remove the packages and install them again.

Let's fix this by increasing the debian_revision:

laforge wrote:

debian policy manual [epoch:]upstream_version[-debian_revision]

so we'd use the -debian_revision

so the upstream versions stays the same but something in the package has changed

History

#1 Updated by osmith 16 days ago

I've implemented the change and found that we can't use debian revision :\

dpkg-source refuses to build the package with "native package version may not have a revision".

I've also tried to use "3.0 (quilt)" instead of "3.0 (native)" (only these two should be used), but then it tries to checkout a git tag with the exact version from the debian/changelog. This is not what we want either, as nightly packages should package most recent commits and not tags.

So I'll just append the build date at the end of the version, that should work.

#2 Updated by osmith 16 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

#3 Updated by laforge 15 days ago

On Wed, Apr 28, 2021 at 10:47:38AM +0000, osmith [REDMINE] wrote:

I've also tried to use "3.0 (quilt)" instead of "3.0 (native)" (only these two should be used), but then it tries to checkout a git tag with the exact version from the debian/changelog. This is not what we want either, as nightly packages should package most recent commits and not tags.

One hack might possibly have been to create a local (non-signed) tag for that version before calling dpkg.

#4 Updated by osmith 15 days ago

  • % Done changed from 50 to 90

#5 Updated by osmith 11 days ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)