Skip to content

Lack of build-datetime in RPM version causes unexpected ordering #209

@pmtk

Description

@pmtk

RPM version comparison works on Epoch-Version-Release. There's nothing about age of the package.
Therefor, when having X.Y.Z-gGIT_COMMIT we're not necessarily providing a new package every night via copr-nightly workflow.

For example, when having two packages in the @microshift-io/experimental-c2cc:

Name         : microshift
Version      : 4.22.0_g1ef7d2d2a_4.22.0_okd_scos.ec.10
Release      : 1.el9

Name         : microshift
Version      : 4.22.0_gd9ee08a84_4.22.0_okd_scos.ec.9
Release      : 1.el9

I was naively surprised that the ec.9 was installed instead of ec.10.

Using rpmdev-vercmp script to compare the two:

$ ./rpm-vercpm.py  --help

rpmdev-vercmp <epoch1> <ver1> <release1> <epoch2> <ver2> <release2>
rpmdev-vercmp <EVR1> <EVR2>
rpmdev-vercmp # with no arguments, prompt

Exit status is 0 if the EVR's are equal, 11 if EVR1 is newer, and 12 if EVR2
is newer.  Other exit statuses indicate problems.

$ ./rpm-vercpm.py 1 4.22.0_g1ef7d2d2a_4.22.0_okd_scos.ec.10 1.el9 1 4.22.0_gd9ee08a84_4.22.0_okd_scos.ec.9 1.el9
1:4.22.0_g1ef7d2d2a_4.22.0_okd_scos.ec.10-1.el9 < 1:4.22.0_gd9ee08a84_4.22.0_okd_scos.ec.9-1.el9


$ echo $?
12

We need to add a yyyymmddHHMM after the first X.Y.Z and before the gCOMMIT

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions