Description of problem:
The problem seems to be that 389-ds-base is linked to db4-utils when I removed that and am using libdb.5.1.
Version-Release number of selected component (if applicable):
I updated cyrus-sasldb to work with sendmail and cyrus-imap to work with the sasldb all linked to libdb.5.1 and "rpm -e --nodeps db4-utils" to resolve compatiblity issues with that upgrade.
Steps to Reproduce:
1. stable fedora 14 pre-upgraded to 15
2. follow https://bugzilla.redhat.com/show_bug.cgi?id=712943
3. follow https://bugzilla.redhat.com/show_bug.cgi?id=729767
4. yum update -y
# yum -y update
389-ds-base i686 188.8.131.52-2.fc15 updates 1.3 M
389-ds-base-libs i686 184.108.40.206-2.fc15 updates 363 k
rpm i686 220.127.116.11-1.fc15 updates 987 k
rpm-build-libs i686 18.104.22.168-1.fc15 updates 91 k
rpm-libs i686 22.214.171.124-1.fc15 updates 245 k
rpm-python i686 126.96.36.199-1.fc15 updates 60 k
ERROR with rpm_check_debug vs depsolve:
db4-utils is needed by rpm-188.8.131.52-1.fc15.i686
db4-utils is needed by 389-ds-base-184.108.40.206-2.fc15.i686
Please report this error in http://yum.baseurl.org/report
** Found 3 pre-existing rpmdb problem(s), 'yum check' output follows:
389-ds-base-220.127.116.11-1.fc15.i686 has missing requires of db4-utils
libpanelappletmm-2.26.0-2.fc12.i686 has missing requires of libpanel-applet-2.so
rpm-4.9.0-9.fc15.i686 has missing requires of db4-utils
Isn't a critical problem and I have been working around updating by
# yum -y update --exclude=389-ds-base* --exclude=libpanelappletmm* --exclude=rpm*
But would be nice to get updates.
How are you using libdb5.1? The version of db4 in F-15 is 4.8.
When i did the pre-upgrade to f15 it went to that. Sendmail used it, cyrus-sasl wanted the 4 version and cyrus-imap wanted the 4 version also. The above bug links fixed those problems linking to the 5.1 version.
# rpm -q libdb
# rpm -q libdb-utils
The problem was that libdb-utils was still db4-utils. they both had the same programs and looks to me as if the developers didn't want the rpm associated with version 4 and changed the name to libdb instead. I had to force the upgrade of the utils package to work with the email system.
cleaned up db4:
#rpm -e --nodeps db4-utils
#yum install libdb-utils
389 is still working and using the 4.8 apparently since that is still installed but the problem with the 'utils' package is what doesn't work since they couldn't co-exist.
#rpm -q db4
#rpm -q db4-utils
package db4-utils is not installed
389 depends on db4 and db4-utils - you can't use db5 utils to manage the 389 databases that use db4. So is this a 389 problem?
I would say yes, not so much in the code perhaps but the compile linker options? If the dependencies are updated (in this case Berkeley DB) then the programs that use them should work with the new also. this is a problem with backwards compatibility on libdb-utils and db4-utils yes, but it also effects like i said my email server. So if 389-ds-base cant use the newer utils, the older utils can't coexist with the newer one, and the email server wont work with the older then you cant run 389 and cyrus email on the same box.
Since i've never compiled 389 or looked at the source I figure it is either a configure option flag to change the library at compile time, or hard-coded include <db.h> that should work if changed to <libdb/db.h> or something like that. Right?
(In reply to comment #6)
> I would say yes, not so much in the code perhaps but the compile linker
> options? If the dependencies are updated (in this case Berkeley DB) then the
> programs that use them should work with the new also. this is a problem with
> backwards compatibility on libdb-utils and db4-utils yes, but it also effects
> like i said my email server. So if 389-ds-base cant use the newer utils, the
> older utils can't coexist with the newer one, and the email server wont work
> with the older then you cant run 389 and cyrus email on the same box.
> Since i've never compiled 389 or looked at the source I figure it is either a
> configure option flag to change the library at compile time, or hard-coded
> include <db.h> that should work if changed to <libdb/db.h> or something like
> that. Right?
Right. I haven't yet looked at db5 but when there has been a major db version change in the past, 389 has required some porting work (see ldap/servers/slapd/back-ldbm/dblayer.c for the gory details, et. al.)
I would prefer that, if db4 is still provided by the OS, that db4-utils would also be provided, in some way that it can co-exist with libdb-utils.
Otherwise, I'll have to go ahead and port 389 to use libdb.
I would rather not have 389-ds-base on f15 ported to use libdb. It will be too disruptive to existing 389 deployments, having to upgrade the database, and manage any headaches caused thereby. It's possible we could get this into f-16, but f-17/rawhide would be better to do something this disruptive.
I suppose you could copy the db4-utils to a different directory, then force the installation of libdb-utils. Then you'd have to be careful when using the 389 command line utilities to put that new directory as the first path of your PATH.
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: