It never fails (bsddb retirement in 2.3)

[Andrew MacIntyre]

On 5 May 2003, Martin v. [iso-8859-15] Löwis wrote:

> Andrew MacIntyre <andymac at bullseye.apana.org.au> writes:
>
> > If we can come up with smarts in anydbm that correctly detects the format
> > of the DB file, so that bsddb185 (or maybe the dbm module?) can be used
> > for these, that would allow deflection of some of the steam.
>
> To do that, whichdb would need to recognize bsddb 1.85. Then, we could
> either provide a module dbhash185.py, or have dbhash.py use either
> bsddb or bsddb185.

I've done some research, and can conclude:
- FreeBSD definitely has DB 1.85 in libc, and the important system
  database files are in 1.85 format (& cannot be upgraded to a later
  format if you still want a usable system).
- as a result, bsddb185 should probably be built by default on FreeBSD.
- I expect, but cannot confirm, that NetBSD and OpenBSD have the same
  requirements.
- I infer from a post by Skip that OS/X also has DB 1.85 in libc, but
  have no idea whether important system files rely on this format.

It is messy but not hard to identify the DB format, and for the above
systems this would be manageable.

Other systems, and Linux in particular, would seem to present some nasty
issues due to the lack of predictability of library version.  It would
seem that quite a few Linux systems end up with DB 2.x and DB 3.x
depending on who builds an installation, and what they have installed at
the time.  Python 2.2.2's setup py looks for the db_185.h compatibility
header (which could come from any Sleepycat v2/3 release) before looking
for the original v1.85 db.h, for instance.

To deal with this would require the modules to export the format version
values they support.  From header files I have copies of:
 v1.85 =>   hash v2
 v1.86 =>   hash v3
 v3.3.11 => hash v7 (but supports back to v4)
 v4.0.14 => hash v7   "     "      "   "  "

I don't have copies of any other Sleepycat source releases to determine
what versions use hash version 4, 5 or 6.

Reactions?

In retrospect, I think a slightly less painful approach would have been to
import PyBSDDB as bsddb3, and just deprecate the original bsddb (letting
it wither except on those systems that absolutely insist).  Too late now I
think.

As an observation, the poster who stirred this pot (who I think was on
Linux) was already on a slippery slope, which an O/S upgrade might have
twitched just as easily as Python.....

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  | Snail: PO Box 370
        andymac at pcug.org.au            |        Belconnen  ACT  2616
Web:    http://www.andymac.org/        |        Australia