OK, as we seem to be getting confused on architectural issues, let me
try to lay out some ground rules.

First of all, the forward looking important object abstractions are
     rpmts	-- transaction set
     rpmte	-- transaction element
     rpmds -- dependency set
     rpmfi	-- file info set
     rpmmi	-- match iterator

Note the conspicuous absence of Header and rpmdb (and dbiSet but only  
a few
know their rpm internals well enough to understand what that object  
is/was). I've quietly
rewritten and refactored rpm code for years to get the 3 primary  
package management
objects _OUT_ of rpm's API/ABI, and I've largely been successful.

Yes, Header's are still used, and are essential for "package  
management". In fact
rpm's primary success (and the reason why XAR is so attractive), is  
that the header object
is moved from *.rpm file to rpmdb mostly untouched. In fact, checking  
header digest/signature
_GUARANTEES_ the header is untouched.

However, for quite some time now, Header's are only a minor object, not
the sine qua non of package management. The remnant usage is that  
Header's
are what is returned from an rpmmi iterator. In most cases, either tag 
(s) or (usually)
dependency sets are stripped from the header, and the header is then  
quietly discarded
as the iteration proceeds.

The rpmdb has beeen almost entirely buried underneath rpmts methods.  
I will rip the
ELF symbols out of librpmdb if I have to make the point perfectly  
clear (and likely I need
to do that so that architectural issues are clarified, this weekend's  
todo++).

The focus needs to be on retrieval of "package" objects through an  
iterator, not
on mundane issues like Berkeley DB <-> SQLite. Both Berkeley DB and  
SQLite
have any number of ways to access databases, rpm does not need to re- 
invent the wheel.

I carefully point out that SQL retrieval invariably involves  
iteration over a row object.
A fancier constructor for an rpmmi, as well as better SQL iterator  
methods (those currently
implemented are peculier to rpm's lowest common denominator  
hierarchical join
operation. See rpmdbPruneIterator() and rpmdbGrowIterator() for what  
I'm talking about).

Does that help clarify? Truly having the mixture of both old <-> new  
rpm objects floating
around is worse than any single abstraction.

73 de Jeff