Bug 198038

Hi Robert,

I'll update to the latest db after FC6 release to keep a well known and stable
version there.

Thanks Jindrich for response. I'm a guy always using the latest version, so I 
tried to upgrade myself which caused me to open bug report #14939 at Sleepycat 
Software, because it looks like they wrote sloppy code. Rebuilding currently
fails, because they are re-defining some stuff shipped with gcc or glibc-devel 
packages. I'll keep this bug report up2date about any problems and failures I 
experience to make the update after FC6 release more easily.

Thanks Robert, this would be definitely helpful.

Okay, closed my bug report at Sleepycat Software. The problem was a regression 
or bug within the compiler which was fixed at least with gcc-4.1.1-9.

Thanks for the info, have you tested the new db4? Did you encounter some other
regressions?

I didn't encounter further problems, but I've got to say, I'm using db4 only
at the iproute, perl, webalizer, mod_perl, pam_abl, php-cli, apr-util, python, 
sendmail and httpd packages and only on ix86 arch. My rpm 4.4.7-0.x package is 
from upstream and uses latest db4, too.

Waiting for db4-4.5.20 (stable) after FC6 was released...

http://people.redhat.com/jnovy/files/db4-4.5.20-1.src.rpm

Testing SRPM. Any feedback is appreciated.

Your package works for me, but I had to do the following things:

- Building pam-0.99.6.2-3 with internal db4-4.5.20 to avoid conflicts etc.
- Patch50 (db-4.3.27-initmem.patch) from cyrus-sasl-2.1.22-4 can be removed
  when using 4.5.20 for internal db4
- subversion-1.3.2-6 as to be rebuilt after apr-utils was built against 4.5.20

Rebuilding of python-2.4.3-18 and subversion-1.3.2-6 failed:

./Modules/_bsddb.c: In function 'DB_length':
./Modules/_bsddb.c:2453: error: 'DB_CACHED_COUNTS' undeclared (first use in this 
function)
./Modules/_bsddb.c:2453: error: (Each undeclared identifier is reported only 
once
./Modules/_bsddb.c:2453: error: for each function it appears in.)
./Modules/_bsddb.c: In function 'DBEnv_set_lk_max':
./Modules/_bsddb.c:3811: error: 'DB_ENV' has no member named 'set_lk_max'
./Modules/_bsddb.c: In function 'init_bsddb':
./Modules/_bsddb.c:5004: error: 'DB_CACHED_COUNTS' undeclared (first use in this 
function)
./Modules/_bsddb.c:5039: error: 'DB_RECORDCOUNT' undeclared (first use in this 
function)
make: *** [Modules/_bsddb.o] Error 1
make: *** Waiting for unfinished jobs....

Running all tests in strings-reps-test...success
At least one test FAILED, checking /usr/src/rpm/BUILD/subversion-1.3.2/tests.log
FAIL:  fs-base-test 2: open an existing Berkeley DB filesystem
At least one test was SKIPPED, checking /usr/src/rpm/BUILD/subversion-1.3.2/
tests.log
SKIP:  utf8_tests.py 1: conversion of paths and logs to/from utf8
SKIP:  authz_tests.py 1: authz issue #2486 - open root
SKIP:  authz_tests.py 2: authz issue #2486 - open directory
make: *** [check] Error 1

The problem rebuilding python using db 4.5 seems to be a bug which is tracked 
down here: https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=1571754&group_id=5470

I submitted a working patch for python resolving this to upstream...

Thanks! I'll try to rebuild the rest of the db4 dependencies next week locally
to be sure we can add the db4-4.5.20 to rawhide as soon as FC6 is released.

Ping?

Any plan when the end of "short time" is reached to break Rawhide?

Yup, I needed to discuss what will be in the upcoming compat-db, what is now
clear so you can expect db4/compat-db upgrade during the weekend, followed by
rawhide breakage ;-)

db-4.5.20 is now built in rawhide.

The new db4 build was untagged because of buildroot breakage caused by conflict
with pam. I'll close this again when it's resolved.

I saw at the lists, rebuild pam using the following in spec file:

  %define db_version 4.5.20
  %define db_conflicting_version 4.6.0

But I told you about this conflict in comment #9, you remember? ;-)

Ah and you should make the compat-db packages ready _before_ pushing the new
db4 package, otherwise you'll run in other unresolved dependency problems...

I know the solution is to remove/update the pam conflict tags, but it's not an
usual practise to modify packages that have a different maintainer before
letting him know at least.

I tried building sendmail 8.14.0-Beta1, and got this nice error message:

/usr/bin/ld: cannot find -ldb
collect2: ld returned 1 exit status

A round of applause for whoever coded the Obsoletes: such that my db4-devel got
de-installed, nuking /usr/lib/libdb.so - this will probably bite others as well.

Obsoletes has nothing to do with it. libdb.so is simply removed as soon as you
remove db4-devel because the devel package only ships the nonversioned .so as a
symlink to a versioned library libdb-4.5.so which is a part of the main db4
package. This is an usual practise for any devel package and it is nothing unusual.

% rpm -q -obsoletes compat-db
...
db4 < 4.4
db4-devel < 4.4
...

So when compat-db got installed by yum, db4-devel evaporated.  Apparently, I hit
a window when compat-db and the new db4 were in the yum repository, but
db4-devel wasn't available yet, so db4-devel got removed rather than upgraded....