[Bug 1042200] Re: poldek doesn't build with rpm 5.4.x

[Jeff Johnson]

Nice!

rpmmiCount() has different implementation in rpm-5.3+

Traditionally, rpmmiCount() was the size of the array of "join keys".

A "join key" is the uint32_t that associates a key in a secondary index
with the header in the primary Packages storage.

In rpm-5.3+, Berkely DB automagically associates the secondary index
key with the header in the primary Packages store. Using DB->associate
permitted removal of ~50% of the code that was previously necessary
to return the header that contains a secondary key. The rpm-5.3 code
is far faster, and also permits *RE patterns against the secondary index
keys without the need to retrieve headers.

(If the above doesn't make sense, think: 1-2 orders of magnitude faster lookup
because of less I/O).

The minor casualty of the faster implementation is that rpmmiCount() behaves differently
than before, and is implemented using an internal Berkeley DB method rather than
simply returning the size of an array. There are subtly different constraints on
the rpmmiCount() usage case than before.

In most rpmdb iteration usage cases, there is little need for calling rpmmiCount()
(based on rpmlib code).

If you post an example of the code in poldek that is using rpmmiCount() on
<rpm-devel at rpm5.org>, I can will suggest alternative implementations
that do not need to explicitly call rpmmiCount().

-- 
You received this bug notification because you are subscribed to PLD
Linux.
https://bugs.launchpad.net/bugs/1042200

Title:
  poldek doesn't build with rpm 5.4.x

Status in poldek:
  Fix Committed
Status in PLD Linux Distribution:
  New

Bug description:
  1) configure fails due to rpmlib.h removal in rpm 5.4
  2) even after working around missing rpmlib.h there is a lot of errors in pm/rpm because of poldek using internal rpm types

To manage notifications about this bug go to:
https://bugs.launchpad.net/poldek/+bug/1042200/+subscriptions