On Dec 8, 2009, at 11:10 PM, Jeff Johnson wrote:

> 
> On Dec 8, 2009, at 4:26 PM, Jeff Johnson wrote:
> 
>> 
>> I'll leave the existing --rebuilddb as "opt-in" with a compile time toggle
>> until, say, Friday 12/11/2009 for comments before
>> hauling out the trash from rpmdb/rpmdb.c.
>> 
> 

OK, inplace --rebuilddb (and major trash hauling out of rpmdb) this weekend.

FWIW, I've managed to get unit tests in place for the most common rpmmi
accesses (including RPMTAG_NVRA patterns, w00t!).

Along the way, I found a missing Header newref in the JS Mi class that
has been bugging me for months. That cleaned up _LOTS_ of issues with
rpmdb/rpmmi linked lists under JS, so I can postpone using atexit(3) (and unwiring
the rpmdb signal handler, relying on Berkeley DB ACID and DB_RECOVER to
fix issues). I'd _STILL_ like to stop masking signals and syncing rpmdb's
needlessly, but that will take a fair amount of burn-in time to establish
"reliability".

The next implementation needed for an rpmdb is to add an index for
RPMTAG_REMOVETID to track re-packaged packages that are (usually)
stored in /var/spool/repackage.

The RPMTAG_REMOVETID schema will save (at least) these items
	NVRA	package N-V-R.A
	HDRID	header SHA1
	PKGID	header+payload MD5
	ORIGIN	a file:///var/spool/repackage/*/N-V-R.A.rpm URL
to attach repackaged packages through a secondary package store.

If/when RPMTAG_REMOVETID is stabilized, the same data model will
be extended first to a RPMTAG_INSTALLTID table for a local store
of the original packages used during an install, and then to
remote repositories by permitting http/ftp URL's.

73 de Jeff	off to load the dumpster with rpmdb bits