i managed to get a backtrace of the segfault when doing rpm -e rpmlint.
i could also provide a core dump, if you want that.
a brief inspection reveals that version and release are both NULL,
thus the segfault. 
further probing wasn't too revealing...

m.

[root@fracas rpm-4.0.2]# ./rpm --rcfile /usr/lib/rpm/rpmrc -e rpmlint
error: cannot open Depends index using db1 - File exists (17)
Segmentation fault (core dumped)
[root@fracas rpm-4.0.2]# gdb ./rpm /core

Core was generated by `./rpm --rcfile /usr/lib/rpm/rpmrc -e rpmlint'.
Program terminated with signal 11, Segmentation fault.
#0  0x806430f in providePackageNVR (h=0x82e71c8) at misc.c:787
787         pEVR = p = alloca(21 + strlen(version) + 1 + strlen(release) + 1);


(gdb) backtrace
#0  0x806430f in providePackageNVR (h=0x82e71c8) at misc.c:787
#1  0x807ab99 in doGetRecord (pkgs=0x819e588, offset=14443672) at db1.c:145
#2  0x807ae07 in db1cget (dbi=0x8199610, dbcursor=0xffffffff, keyp=0xbffff2d0,
keylen=0xbffff2d4, datap=0xbffff2d8, 
    datalen=0xbffff2dc, flags=0) at db1.c:258
#3  0x8068557 in dbiGet (dbi=0x8199610, dbcursor=0xffffffff, keypp=0xbffff2d0,
keylenp=0xbffff2d4, datapp=0xbffff2d8, 
    datalenp=0xbffff2dc, flags=0) at rpmdb.c:191
#4  0x806a3ea in XrpmdbNextIterator (mi=0x81d0910, f=0x815e662 "rpmdb.c",
l=2009) at rpmdb.c:1370
#5  0x806b96a in rpmdbFindFpList (rpmdb=0x8199588, fpList=0x81c6a20,
matchList=0x81d0870, numItems=38) at rpmdb.c:2062
#6  0x8076aa0 in rpmRunTransactions (ts=0x819e680, notify=0, notifyData=0x0,
okProbs=0x0, newProbs=0xbffff8ac, transFlags=0, 
    ignoreSet=RPMPROB_FILTER_NONE) at transaction.c:1658
#7  0x806e078 in rpmErase (rootdir=0x81588ac "/", argv=0x8194ac0, transFlags=0,
interfaceFlags=0) at rpminstall.c:592
#8  0x804d9f3 in main (argc=5, argv=0xbffff9f4) at rpm.c:1089

Your database probably had problems before you upgraded to rpm-4.0.2., and
the db1 handling in rpm-4.0.2 with damaged data is not as good as rpm-3.0.x

Workaround by doing a rebuilddb with rpm-3.0.5:
	1) get a copy of rpm-3.0.5 packages
	2) unpack in a temp directory
		mkdir -p /var/tmp/xxx
		cd /var/tmp/xxx
		rpm2cpio rpm-3.0.5-*.rpm | cpio -dim
	3) rebuilld to eliminate damaged record using rpm-3.0.5
		cd /var/tmp/xxx
		./bin/rpm --rebuilddb
	4) rebuild to convert from db1 to db3 using rpm-4.0.2
		/bin/rpm --rebuilddb

Does that fix your problem?

Unfortunately, not.
I rebuilt the DB with rpm 3.0.6 and it skipped a record that
was giving problems, but rebuiding with rpm 4 still segfaults
in the same place.

do i need some way of telling rpm 4 to rebuild from the rpm 3 indexes? 

[root@fracas bin]# ./rpm --rebuilddb
record number 14443672 in database is bad -- skipping.
[root@fracas bin]# /bin/rpm --rebuilddb
Segmentation fault

OK, you still have damaged records in your database, but the damge is to the
header
itself, not the chain. Deleting the record (by erasing the package) should fix.

No, you don't have to anything special with the indexes (i.e. everything in
/var/lib/rpm
execept Packages or packages.rpm, as the damage is in packages.rpm.

You can detect the damaged record by
	1) Run "rpm --rebuilddb -vv" using rpm-4.0.2, and note the last package
	before the segfault.
	2) Run "rpm --rebuilddb -vv" using rpm-3.0.6, and note the package
	with the damage. Erase that package.
	3) Rebuild to convert from db1 to db3 using rpm-4.0.2
		/bin/rpm --rebuilddb

Note: You might want to clean up the /var/lib/rpmrebuild* directories left
after the segfaults.

FWIW,  the patch to rpm-4.0.2 to avoid the segfault is pretty trivial, already
in
rpm CVS on the rpm-4_0 branch, if you want.

so i followed the instructions from the last note - 

1) i rebuild with rpm 4.0.2 and noted the last package mentioned before the
segfault.

2) i then rebuilt with rpm 3.0.6 - it generated no errors.

3) i then removed the package from 1) and tried to rebuild with 4.0.2 again,
but it still segfaulted.

i repeated this 2-3 times, but rpm 4 still segfaults when rebuilding the DB.

so, if there are no issues with this, i'm planning on downgrading to rpm 3
and using it, rather than using a cvs snaphot version of rpm 4.  will using
rpm 3 cause any compatibility issues and/or further database mangling?

If you don't have a "fix" yet, reopen this bug with a pointer to a tarball of
your database
	cd /var/lib
	tar czvf /tmp/rpmdb.tar.gz rpm
and I'll see what's up.