It's likely time to plan to support multiple rpmdb databases,
and possibly with multiple implementations like Berkeley DB
and sqlite.

The specific usage case is for a integrated rpm depsolver. Ignoring
all the transport and import/export representation issues, the
underlying need is the ability to discover what package matches
a given requires.

Re-using the existing rpmdb code, particularly the iterator that
is used for all retrievals, makes lots of sense to me.

What that means is the iterator would need to add an additional loop
over multiple databases, and would need to supply additional information
about which rpmdb contains the header returned by the iterator.

There's the usual baggage configuring multiple paths, and attaching
attributes like RDONLY or RDWR, as well as identification of usage,
that will likely need doing.

So far, I've been planning to turn %_dbpath into a colon separated path
to multiple databases, the first of which is the gud old /var/lib/rpmdb
with RDWR.

There is also the existing %_solve_dbpath. There is  a need for a per- 
rpmts
database for headers passed to rpmtsAddInstallElement that could/should
be used to eliminate the nasty code with a largish in-memory  
footprint in
lib/rpmal.c.

But if other means to an "integrated dependency solver" for rpm-5.0 are
desired, it's likely time to warn me now ;-)

73 de Jeff