Recently a package went from Epoch: 0 to just not listing epoch at all. This was supposed to work, and it does if using say rpm -Uvh or yum to attempt the upgrade. However the rpm python bindings seem to think that epoch of None is somehow lower than epoch 0 and thus tools doing version comparison in python get this wrong. print rpm.labelCompare((None, '1.5.0.9', '7.fc6'), ('0', '1.5.0.9','2.fc6')) -1 print rpm.labelCompare(('0', '1.5.0.9', '7.fc6'), ('0', '1.5.0.9','2.fc6')) 1 As part of the packaging cleanup for the merger of core/extras, we wanted to remove the unnecessary Epoch: 0 entries in spec files, but this may block us form doing so.
Yep. labelCompare() has never been taught Mising Epoch: should be treated exactly the same as Epoch: 0 FWIW, there are better EVR comparison API's available than labelCompare() many years now.
Created attachment 147750 [details] Test spec file Jesse - I don't think the actually impacts yum. Try building attached spec file, installing, remove epoch, bump release or version, rebuild and use yum localupdate.
This isn't about yum. Bill Nottingham has a script that compares the verisons of packages that are in the update directories, to prune the old ones. The script is using rpm python bindings to do the comparison, and this is why we discovered that the python binding is miscomparing things that go from Epoch: 0 to None.
*** Bug 229637 has been marked as a duplicate of this bug. ***
Fixed in rpm cvs, will be in rpm-4.4.9-02 when built.
This isn't an F7 blocker IMHO, removing from tracker.
Fixed in rpm.org, will be in rpm 4.4.2.1 as well.
CLOSED
Fixed in next rawhide push by rpm 4.4.2.1-rc1