When I look at the ebuilds app-arch/rpm-4.4.6-r6 and 4.4.6-r7 the dependency is >=sys-libs/db-4. However for app-arch/rpm-4.4.7-r4 this is =sys-libs/db-3.2 ? Shouldn't it be >=sys-libs/db-4 too? I came across this because sys-libs/db-3.2 depends on sys-libs/db-1.85 and for some unknown reason, these packages always want to rebuild when I do a emerge -uNDav world... When dependency is changed for app-arch/rpm-4.4.7-r4 I can unmerge sys-libs/db-3.2 and sys-libs/db-1.85... I can't find any info about dependencies on the website rpm.org neither on the download-site, but it would supprise me that older versions would depend on newer versions of sys-libs/db... Reproducible: Always Expected Results: RDEPEND = ">=sys-libs/db-4 ..."
Actually if you look at the INSTALL file inside source tarball you will see stated deps: ----- Note: rpm-4.0 on Red Hat 7.0 is currently using zlib-1.1.3 db1-1.85 db3-3.1.14 bzip2-1.0.1 gnupg-1.0.2 ------ But...since I realized that this is obviously kind of outdated information (since it mentions 4.0, not 4.4.x)...I dig deeper :-) CHANGES files mentions they changed internal db to 4.5.20 when going from 4.4.6 to 4.4.7. So I guess you are right about being able to use never db. I'll fix this in -r5 Nevertheless, all current versions of rpm have numerous flaws, one of the biggest is that they confuse users IMO. They are not classic rpm, but rpm5 fork (even rpm-4.*). I am working on transition so that we can get rid of these outdated rpm versions and start using current rpm used in Fedora 13. If you want to help me out, start by unmasking rpm-4.8.0 and try it out (I recommend backing up your rpmdb just in case though) :-)
OK, I fixed it in CVS. ebuild should hit servers in a few hours. Please test r5 as *potentially* it can break already created rpmdb (since we changed major version of db). Unfortunately I cannot test this properly because I am myself on x86, so 4.4.7 doesn't work for me...
