Bug 745168

Summary: db4-utils is needed by 389-ds-base
Product: [Fedora] Fedora Reporter: Timothy Sink <tim>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: edewata, nhosoi, nkinder, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 18:14:01 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:
Bug Depends On:    
Bug Blocks: 743970    

Description Timothy Sink 2011-10-11 14:44:56 UTC
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):


How reproducible:
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
  
Actual results:

# yum -y update
Updating:
 389-ds-base                                i686                           1.2.9.10-2.fc15                           updates                           1.3 M
 389-ds-base-libs                           i686                           1.2.9.10-2.fc15                           updates                           363 k
 rpm                                        i686                           4.9.1.2-1.fc15                            updates                           987 k
 rpm-build-libs                             i686                           4.9.1.2-1.fc15                            updates                            91 k
 rpm-libs                                   i686                           4.9.1.2-1.fc15                            updates                           245 k
 rpm-python                                 i686                           4.9.1.2-1.fc15                            updates                            60 k


ERROR with rpm_check_debug vs depsolve:
db4-utils is needed by rpm-4.9.1.2-1.fc15.i686
db4-utils is needed by 389-ds-base-1.2.9.10-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-1.2.9.6-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


Expected results:


Additional info:
   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.

Comment 1 Rich Megginson 2011-10-12 15:07:11 UTC
How are you using libdb5.1?  The version of db4 in F-15 is 4.8.

Comment 2 Timothy Sink 2011-10-12 15:18:06 UTC
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
libdb-5.1.25-3.fc15.i686
# rpm -q libdb-utils
libdb-utils-5.1.25-3.fc15.i686

Comment 3 Timothy Sink 2011-10-12 15:23:34 UTC
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
installed libdb
#yum install libdb-utils

Comment 4 Timothy Sink 2011-10-12 15:29:37 UTC
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
db4-4.8.30-3.fc15.i686
#rpm -q db4-utils
package db4-utils is not installed

Comment 5 Rich Megginson 2011-10-12 16:19:31 UTC
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?

Comment 6 Timothy Sink 2011-10-12 18:14:59 UTC
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?

Comment 7 Rich Megginson 2011-10-12 18:27:20 UTC
(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.

Comment 8 Rich Megginson 2011-10-20 00:00:35 UTC
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.

Comment 9 Rich Megginson 2012-01-09 15:38:49 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/169

Comment 10 Fedora End Of Life 2012-08-07 18:14:04 UTC
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping