Bug 24341

Summary: librpm incorrectly links against libdb-3
Product: [Retired] Red Hat Linux Reporter: Robin * Slomkowski <rslomkow>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-01-19 21:08:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robin * Slomkowski 2001-01-19 07:44:38 UTC
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.

Comment 1 Jeff Johnson 2001-01-19 16:25:51 UTC
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.

Comment 2 Robin * Slomkowski 2001-01-19 21:08:19 UTC
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.

Comment 3 Jeff Johnson 2001-01-19 21:17:40 UTC
rpm does not support db2 format, never will, support for db1 is being dumped
soonest as well.

Comment 4 Robin * Slomkowski 2001-01-19 21:32:14 UTC
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.