The dbMatch() method of TransactionSet objects (as created by
rpm.ts()) fail to match any packages when using numeric keys, such as
iterator offsets, on any 64bit machine.
For instance, the following Python snippet will always show '0' (no
matched packages) as output, no matter what "offset" is used.
ts = rpm.ts()
mi = ts.dbMatch(0, offset)
As previously discussed with Jeff Johnson, the problem here is that
the "key" parameter, when numeric, is converted to a long and passed
to the rpmlib as such, but rpmlib expects an "int" instead (32bit).
This problem is seriously affecting Smart Package Manager usage on
64bit platforms, as many Fedora Core users have reported.
Version-Release number of selected component (if applicable):
4.3, 4.4, ...
Fixed on HEAD, rpm-4_4, and rpm-4_3 branches, (rpm-4_2 no fix needed).
will a release pushed for Fedora Core 3 with this fix?
Fixed in rpm-4.4.1-0.18.
So no fix for FC3 ? Not even when I say pretty please ? :)
The bug makes Smart(pm) useless on FC3/x86_64. And if EL4 ships with
something older than 4.4.1-0.18, it'll fail on EL4/x86_64 too...
Where do I have to donate to get RPM 4.4.1 backported back to EL2 ? :)