gdbm 1.8.3 critical regressions and API messups

[Matthias Andree]

Hi,

to let my non-objective fury off right away:

I am pissed and annoyed by gdbm's recent quality decreases that struck
me out of the void.

My apologies if it sounds harsh, don't take it as personal offense, but
as criticism of the procedures employed in maintaining gdbm, it's not
meant as ad-hominem attack.

Getting back to a objective and constructive level:

As a preface, please read Zack Weinberg's recommendations at
http://www.panix.com/~zackw/exbib/2002/June/20

I believe these match the procedures in projects inside and outside of
GNU.

I used "vacation" on a SuSE 7.0 box with some older gdbm library 1.7 or
1.6 or whatever was current in 2000. "vacation" used libgdbm.so.1, it
worked nicely across NFS.

I then decided to upgrade to SuSE 8.1, which ships gdbm 1.8.0, API
version libgdbm.so.2, so vacation stopped working, libgdbm.so.1 was gone
after the update. Bad enough, gdbm 1.8.0 should have been called 2.0.0.
-> Unsuspected incompatibility.

I recompiled vacation against the new gdbm; it would link again, but
still didn't work: "no locks available", I strace-d this down to gdbm's
use of "flock()", which doesn't work on NFS with Linux 2.4.

I figured I would have to recompile gdbm to disallow flock and use fcntl
instead, so I chose the latest version, gdbm 1.8.3. To my astonishment,
vacation would no longer link, because gdbm now installed libgdbm.so.3,
when gdbm should have be named 3.0.1 or something rather than 1.8.3.

These careless changes in gdbm made on September 25, together with the
NFS regressions, make gdbm a rather unreliable package at the moment,
which is a sad thing. I am VERY annoyed.

To reinstate trust and limit the impact of these incidents, I have some
suggestions:

1. remove all gdbm version that are named 1.8.X but install
   libgdbm.so.3, and re-release them as 2.0.X. I'm not going to check
   if 1.8.0, 1.8.1 or 1.8.2 is the last version that installs gdbm.so.2.
   The "libgdbm.so.2 has 1.8.x version number rather than 2.0.X" cannot
   be cured now that SuSE ship gdbm 1.8.0.

2. switch back to use fcntl() on systems that have it, and use flock()
   ONLY when fcntl() is unavailable. This is required for NFS compatibility.

Please consider this patch:

--- ./systems.h.orig    2002-10-07 20:44:31.000000000 +0200
+++ ./systems.h 2002-12-14 16:25:53.000000000 +0100
@@ -61,7 +61,7 @@
 
 /* Do we have flock?  (BSD...) */
 
-#if HAVE_FLOCK
+#if !HAVE_FCNTL_H
 
 #ifndef LOCK_SH
 #define LOCK_SH        1

3. clearly mark any API (i. e. libgdbm.so.3 to libgdbm.so.4) changes
   a) in the NEWS file   b) by stepping the major release number.

4. best lay down the policy change in the NEWS file

Please let me know on short notice (by December 22nd, 2002) what you are
going to do about these incompatibility problems and how you're going to
prevent these major irritations in the future.

These incidents are most annoying and ready to harm the reputation of
the whole GNU project, and the procedures used when versioning the gdbm
library are unacceptable. gdbm must be considered harmful and unstable
unless the policy gets aligned to common practice.

Best wishes,

-- 
Matthias Andree