View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007671||CentOS-7||createrepo||public||2014-10-05 20:23||2014-10-06 17:17|
|Summary||0007671: createrepo's rpm version parsing differs from librpm producing incorrect metadata|
|Description||createrepo has a bug in its python code for parsing version strings from RPMs. This bug was fixed, but the fix was lost during a major rewrite of the createrepo internals.|
The commit sha 2269134f119ce13d6a9b725f94954d9dd629f427 in the createrepo git history contains the fix that should exist on master, but was instead lost.
You can find the librpm algorithm for computing version, release, and epoch in the function 'parseEVR' in rpmds.c in librpm (I am looking at the source for librpm-126.96.36.199, but this code is present in earlier versions).
The result is that the primary XML produced by createrepo (and used in the official CentOS7 repositories) lists different version and release strings for rpm provides than would be listed by librpm.
For example, the package plexus-cdc-1.0-0.20.a14.el7.noarch.rpm from CentOS7 has the following in its primary xml:
<rpm:entry epoch="0" flags="EQ" name="mvn(org.codehaus.plexus:plexus-cdc)" rel="14" ver="1.0-alpha"/>
But librpm generates: ver="1.0" and release "alpha-14"
|Tags||No tags attached.|
Err, looks like I wrote that backward..
<rpm:entry name="mvn(org.codehaus.plexus:plexus-cdc)" flags="EQ" epoch="0" ver="1.0" rel="alpha-14"/>
<rpm:entry name="mvn(org.codehaus.plexus:plexus-cdc)" flags="EQ" epoch="0" ver="1.0-alpha" rel="14"/>
Yep, I filed the RH bug as well.
I forgot to mention: once this bug is fixed in createrepo, the official CentOS7 repositories should probably be generated as the official metadata is currently outputting incorrect version and release strings for several packages.