Its approaching time to figure a rpmdb solution for
the Berkeley DB haters.

So far, I've left the existing sqlite3 code in place, and
added noop methods for a few additional database operations.

But development on HEAD now includes support for transactions, and
abstract log events, and DB_RECOVER transaction aborts, that will
never function with the existing sqlite3 implementation as is. The
additional functionality is conditioned on INIT_TXN flags; if not
set, the methods do nothing. But adding a disabler is only mechanism,
increasingly RPM is going to rely on rpmdb ACID behavior.

I note (in passing) that sqlite3 has been removed from @rpm.org
	http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=e2c217b4b76118e6dab9f8dfb3284bb4ddbe2b3e

There's no reason (other than complexity) why a SQL implementation,
including ACID behavior, cannot be attempted.

There's also no reason why some dirt simple database implementation
based on the thundering herd of ndbm(3) API clone's cannot be
attempted.

How and when that work is done is an open question. I'm willing
to do the work, but I cannot say when.

No matter what:
	The existing rpmdb schema and implementation has changed.
	The incompatibilities will be dealt with through conversion,
	not by continuing legacy support for the older rpmdb formats.

So what issues are there with continuing (or removing) the existing sqlite3
support @rpm5.org?

73 de Jeff