Bug 44417 – OpenLDAP server uses GDBM instead of Berkeley DB?

Bug 44417 - OpenLDAP server uses GDBM instead of Berkeley DB?

Summary:	OpenLDAP server uses GDBM instead of Berkeley DB?

Status:	CLOSED DEFERRED

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	openldap (Show other bugs)
Sub Component:
Version:	7.1
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Nalin Dahyabhai
QA Contact:	Aaron Brown
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2001-06-13 11:20 EDT by Chris Adams
Modified:	2007-04-18 12:33 EDT (History)
CC List:	0 users

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2001-06-13 11:20:55 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Chris Adams 2001-06-13 11:20:51 EDT

Why does Red Hat configure OpenLDAP to use GDBM instead of Berkeley DB? 
The
OpenLDAP authors recommend the Berkeley DB for the backend and (from the
list archives) say that it will give better performance.

The only explanation I can see is this entry in the .spec file changelog:

* Mon Jul 10 2000 Nalin Dahyabhai <nalin@redhat.com>
- switch to gdbm; I'm getting off the db merry-go-round

What is that suppoed to mean?

Comment 1 Nalin Dahyabhai 2001-07-03 16:25:20 EDT

Applications linked against DB2 which link against OpenLDAP compiled with
DB3 will die strangely because the two libraries provide functions with
the same names (__db_open and friends).

It's more of a namespacing issue until we can safely sort this multiple-
version mess out ("safely" means without having things break unexpectedly,
i.e., a major release, when breakage is expected).  Marking as deferred.

Note You need to log in before you can comment on or make changes to this bug.