It never fails (bsddb retirement in 2.3)

[Skip Montanaro]

    Andrew> - I infer from a post by Skip that OS/X also has DB 1.85 in
    Andrew>   libc, but have no idea whether important system files rely on
    Andrew>   this format.

/etc/pwd.db is in Hash format v2 - the hash file format used by db 1.85.

I'm testing out a change to setup.py which will build the bsddb185 module if
and only if /usr/include/db.h exists and defines the cpp symbol HASHVERSION
to be 2.  I think that will be restrictive enough to prevent accidentally
building bsddb185 with a later version of the db library.

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

    Andrew> Other systems, and Linux in particular, would seem to present
    Andrew> some nasty issues due to the lack of predictability of library
    Andrew> version.

Yes, this is an ongoing problem.  It's also a problem for users on Mac OS X
who use fink.  For example, I executed fink updateall the other day.  It
wanted to update /sw/bin/python to 2.3b1, and had a dependency on db4.  Now
I have a mixed db3/db4 system again.  *sigh*

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

Probably good to document somewhere (perhaps as a comment in _bsddb.c).  If
you look at whichdb.py I think you'll see it already wades around in the
beginning bits of database files.  Getting it to distinguish various db hash
file formats shouldn't be too big a deal.  The bsddb185 module could be
tweaked with one new (undocumented) symbol, "open" which refers to
"hashopen".  Whichdb could then return "bsddb185" when it detects a v.2 hash
file.

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

This has happened to me in the past (I thought Nick was running some ancient
DEC Unix though).  You just suck it up, run db_dump (or db_dump185) and
db_load to recreate files in the proper format.

Skip