Bug 2527

Summary: Missing ndbm.h file
Product: [Retired] Red Hat Linux Reporter: caperry
Component: gdbmAssignee: David Lawrence <dkl>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: ct7, smanes
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-05-14 20:15:35 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:

Description caperry 1999-05-03 23:43:11 UTC
The file ndbm.h is missing from this package.  It is
included with the gdbm source from GNU, but it is not in any
packages.  Apache + mod_ssl and/or mod_rewrite requires that
file.

Comment 1 Jeff Johnson 1999-05-04 14:40:59 UTC
There are several different ndbm emulations (e.g. db1 and db2) that
would like the honor of being THE ndbm.h. Try using db1 by
including <db1/ndbm.h> and linking with -ldb1.

GDBM also has a GPL rather than a LGPL license.

Comment 2 niles 1999-05-06 20:43:59 UTC
This is unacceptable!  The Open Group's single UNIX spec
clearly idenitifies the path as <ndbm.h>.  So there needs to
be a choice made and a symbolic link added at least.  There
must exist a file /usr/include/ndbm.h to meet the UNIX spec.

Comment 3 caperry 1999-05-06 21:55:59 UTC
I still do not understand why the ndmb.h file from the gdbm library
cannot be used.  Recompiling with a different library causes much more
grief than it's worth, especially if you are using a huge package like
Apache with mod_ssl.  ReWriting all those makefiles to use db1 or db2
just seems foolish with the file from the gdbm package works out of the
box.  Does it really matter if the package is GPL or LGPL, especially
since it's already in the distribution.  Why can't the distribution be
complete?

Comment 4 ct7 1999-05-12 21:25:59 UTC
Previously RedHat shipped this in glibc-devel-2.0.7-29.i386.rpm; why
isn't it being shipped now in glibc-devel-2.1.1-6.i386.rpm?  This is a
lousy way to treat people who are upgrading from previous versions --
I'm sure I could go back through all of my older RH5.X disks and find
that ndbm.h was in /usr/include ... why move it now?

The GPL license shouldn't be an issue since the GNU libraries are
being delivered as part of the base operating system.

Comment 5 Jeff Johnson 1999-05-14 20:15:59 UTC
There is no way that Red Hat can supply an ndbm.h without
annoying someone. As I said before, there are several different
candidates (e.g. gdbm, db1, db2) that supply a ndbm emulation,
each of which has an incompatible database format.

Choose which database format works for you and create a symlink to
/usr/include/ndbm.h. For example, if you want db1 emulation then do as
root
	ln -s db1/ndbm.h /usr/include/ndbm.h

Comment 6 smanes 1999-08-05 17:21:59 UTC
This solution (link db1/ndbm.h to /usr/include/ndbm.h) won't fix the
Perl 5.005.03 compile problems.  Apparently, the db1 NDBM library
doesn't permit null keys, which Perl supports in its hashes. That's
what is causing the anydbm.t test failures anyway, i.e.

$h{''} = "bar";
print ($h{''} eq 'bar' ? "ok 12\n" : "not ok 12\n");