Bug 745168
Summary: | db4-utils is needed by 389-ds-base | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Timothy Sink <tim> |
Component: | 389-ds-base | Assignee: | Rich Megginson <rmeggins> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 15 | CC: | 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
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 libdb-5.1.25-3.fc15.i686 # rpm -q libdb-utils libdb-utils-5.1.25-3.fc15.i686 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 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 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. Upstream ticket: https://fedorahosted.org/389/ticket/169 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 |