"Martin v. Löwis" writes:
> Matthias Klose wrote:
> > Next thing to investigate, if the archives generated by the gdbm
> > implementation are binary compatible with the ones created by the
> > libdb1 implementation...
>
> Most definitely not: gdbm produces a different binary format than
> db1 (which is BDB 1.85). Traditionally, the 'dbm' module would
> produce what is the "native" dbm format of the system. On Linux,
> this depends on the distribution; if Debian was using db1 all along,
> it should either continue to do so, or drop the dbm module
> altogether.
>
> If people need access to BDB 1.85 database files, in Python 2.3,
> they should best use the bsdb185 module; the distributor should
> guarantee that this is always built against BDB 1.85 (or a library
> that emulates not only the BDB 1.85 API, but also the BDB on-disk
> format, such as Sleepycat BSDDB 2).
emulating the BDB 1.85 API can be done using the db_185.h header of
the libdb4.1-dev package, not sure about the BDB on-disk format.
Is there a similiar workaround for 2.2.3? Of course the bsddb185
module could be backported.
> > at least gdbmmodule.c reads: "Please note that the file formats
> > created by GDBM and dbm are incompatible." Or are the files
> > compatible, if gdbm is used via the gdbm-ndbm.h interface?
>
> They are really incompatible. The OP might not care about on-disk
> compatibility if the API compatibility is provided, but given past
> experience, I'd advise not to silently link dbm.so against a different
> ndbm implementation.
ok.
what about deprecating the use of the dbm module upstream for 2.3?
Matthias
