This problem exits in RH 7.0 and in RAWHIDE rpms of rpm. librpm links against a version of libdb that rpm does not use on the system. It links against libdb-3 while the rpm command and the databases are in libdb2 format. This will cause applications that link against it to not be able to read the rpm database. If I rebuild the source rpm on a default redhat 7.0 install I do not get this libdb-3 in the link line. This implies that there is some problem with the build machine that produces this rpm, as it adds an unessesary and and problematic dependency. /usr/lib/librpm.so dynamicly links with libdb-3 [rslomkow@svadilfari rslomkow]$ ldd /usr/lib/librpm.so.0 libdb-3.1.so => /lib/libdb-3.1.so (0x4004c000) libdb.so.2 => /usr/lib/libdb.so.2 (0x400c8000) libc.so.6 => /lib/libc.so.6 (0x400d6000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) This affects the rpmview in nautilus http://nautilus.eazel.com hourly builds available at http://developer.eazel.com/download/eazel-redhat7/hourly/current/ It will return error messages saying it cannot read the rpm database because it is version dbm version 2. This means to distribute nautilus for RH 7 systems we need to upgrade the rpm package simply to remove this bogus dependency, which is undesirable. We would rather people use official redhat packages where they can.
You're confusing the file name with the version of db used. libdb.so.2 is db1 libdb-3.1.so is db3 Both libraries are currently necessary for rpm-4.0.x in order to provide a means to convert from db1 to db3 format. If you don't get both sonames, then you are rebuilding rpm incorrectly.
my application returns this message. =========================================================================== trilobite-eazel-install-service-Message: Eazel Package System - rpm4 cannot open Packages index using db3 - Invalid argument (22) --> The rpm database cannot be opened in db3 format. If you have just upgraded the rpm package you need to convert your database to db3 format by running "rpm --rebuilddb" as root. =========================================================================== Here is what file reports my rpm datbases. =========================================================================== [local@localhost local]$ file /var/lib/rpm/* /var/lib/rpm/Basenames: Berkeley DB 2.X Hash/Little Endian (Version 7, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2048, Last Freed 619, Max Bucket 0, High Mask 0x0, Low Mask 0x0, Fill Factor 0, Number of Keys 0) /var/lib/rpm/Conflictname: Berkeley DB 2.X Hash/Little Endian (Version 7, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2048, Last Freed 0, Max Bucket 0, High Mask 0x0, Low Mask 0x0, Fill Factor 0, Number of Keys 0) /var/lib/rpm/Group: Berkeley DB 2.X Hash/Little Endian (Version 7, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2048, Last Freed 0, Max Bucket 0, High Mask 0x0, Low Mask 0x0, Fill Factor 0, Number of Keys 0) /var/lib/rpm/Name: Berkeley DB 2.X Hash/Little Endian (Version 7, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2048, Last Freed 3, Max Bucket 0, High Mask 0x0, Low Mask 0x0, Fill Factor 0, Number of Keys 0) /var/lib/rpm/Packages: Berkeley DB 2.X Hash/Little Endian (Version 7, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2048, Last Freed 642, Max Bucket 0, High Mask 0x0, Low Mask 0x0, Fill Factor 0, Number of Keys 0) /var/lib/rpm/Providename: Berkeley DB 2.X Hash/Little Endian (Version 7, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2048, Last Freed 6, Max Bucket 0, High Mask 0x0, Low Mask 0x0, Fill Factor 0, Number of Keys 0) /var/lib/rpm/Requirename: Berkeley DB 2.X Hash/Little Endian (Version 7, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2048, Last Freed 0, Max Bucket 0, High Mask 0x0, Low Mask 0x0, Fill Factor 0, Number of Keys 0) /var/lib/rpm/Triggername: Berkeley DB 2.X Hash/Little Endian (Version 7, Logical sequence number: file - 0, offset - 0, Bucket Size 4096, Overflow Point 2048, Last Freed 0, Max Bucket 0, High Mask 0x0, Low Mask 0x0, Fill Factor 0, Number of Keys 0) ============================================================================ so my actually rpm database is db2, but the rpm commad is statically linked. So it does not use librpm linked in this way. The version of librpm that I find works. [rslomkow@localhost rslomkow]$ ldd /usr/lib/librpm.so.0 libdb.so.2 => /usr/lib/libdb.so.2 (0x400c8000) libc.so.6 => /lib/libc.so.6 (0x400d6000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) this succesfully reads the db files. Now my application links against libdb.so.3 (DB2) If you would like to give me a set of test cases I may be able to give you a formal testing data that shows a system with librpm without libdb3 performs fine.
rpm does not support db2 format, never will, support for db1 is being dumped soonest as well.
Please correct my summary where I am wrong! rpm 4.0.x currently uses db1. The file command incorrectly returns the value type of database that rpm stores its data in as db2, when it is actually db1 on a RH7.0 system. In future releases of rpm, the database format will be stored in db3, and you have begun linking against that now, even though the rpm dbs are not stored in that format. I need to figure out how to convince the loader to resolve db1 symbols before db3 symbols for my application to read current rpm databases.