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
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions