...

...

...

...

"GvR" == Guido van Rossum writes:

GvR> Sounds like a good plan, but we should make sure it can all GvR> be re-released under the PSF license. For the Zope GvR> Corp. portions of the code I promise that's no problem :-) -- GvR> but there are so many other contributors that it's getting a GvR> little tangled... I /think/ we're just talking mostly about Robin Dunn and Andrew Kuchling. From the description on the page, I can't quite tell whether any of Gregory P. Smith's original code remains. i'm-sure-andrew-won't-mind-either-ly y'rs, -Barry

Sounds like a good plan, but we should make sure it can all be re-released under the PSF license. For the Zope Corp. portions of the code I promise that's no problem :-) -- but there are so many other contributors that it's getting a little tangled...

Ok, I'll investigate. Martin

- It'd be great if we actually provided bsddb1, bsddb2, bsddb3 (and bsddb4?) modules which compile against the older libraries so databases written with any version could be accessed in Python. Maybe that's not exactly the right way to do it, but I don't think Python should be limited to just one version of Berkeley db. I've no idea what the default ought to be -- there's no clear winner.

I'm not sure how that would work, though. Are you thinking of different code bases for the modules, or just compiling the same module multiple times? If the latter, how do you deal with features that are available only in later versions? E.g. I doubt that the current _db.c compiles with bsddb2 (not sure it even compiles with 3.0; it may be that 3.1 is required as a minimum). This *could* be solved with lots of #ifdefs in _db.c, but that sounds difficult to get right (who has so many versions installed to actually test that?). Also, I think it is rare that multiple versions are installed on a single system: I doubt BSDDB even supports simultaneous installation of multiple header file sets, on Unix. So even while you can have multiple versions of the shared library installed, compiling it for use with these libraries may be tricky. About the only case where I know about different systems is on Linux, where glibc incorporates a version of BSDDB2, so you might find database file of that version that the more recent BSDDB3 cannot open, anymore. For any other scenario, users are to blame for forgetting to update their database files when updating the libraries. Regards, Martin

...

...

...

...

"SM" == Skip Montanaro writes:

>> - It'd be great if we actually provided bsddb1, bsddb2, bsddb3 >> (and bsddb4?) modules which compile against the older libraries >> so databases written with any version could be accessed in >> Python. Martin> I'm not sure how that would work, though. SM> Agreed. Oops. I thought I had read that pybsddb could be compiled against older APIs. But on a re-read of the pages, that's obviously wrong, so forget this dumb idea. SM> What would be useful is if whatever bsddb module is installed SM> could be more intelligent about file version errors. +1 Martin> Also, I think it is rare that multiple versions are Martin> installed on a single system: I doubt BSDDB even supports Martin> simultaneous installation of multiple header file sets, on Martin> Unix. SM> Actually, RedHat & Mandrake do. This leads to as many SM> problems as it solves. Indeed, this is broken on Mandrake. I was trying to get Postfix and Python to at least agree on the BDB version they were going to use and it wasn't until I installed pybsddb from source, and rebuilt Postfix against the separately downloaded Berkeley 3.3.11 libs/API that I got it all to work. SM> Take a look at the code in setup.py: BTW, I think this a large part of the problem when building Py2.2 on Mandrake 8.1. Maybe these lines in the setup are /too/ smart? I seem to remember having no problems w/ Py2.1.1. But that's excusable I suppose since pybsddb's setup.py has its own problems! It should at least recognize a default from-source install of Sleepycat's libs w/o lots of cryptic command line options. And getting "python setup.py clean -a" to work right would be a bonus. :) Also note that pybsddb should now (or soon) work with Berkeley DB 4 so calling it bsddb3 isn't right either. I don't think there's a db format change from BDB 3 -> BDB 4. bsddb-ng? :) Okay, I'm rambling. Let's add pybsddb (under a better name) and keep bsddbmodule around and /try/ to fix some of the worst installation problems. The state of Berkeley DB on various distros doesn't make our lives easy here, but let's not add to the problems, if at all possible. I'm willing to help out with all this. We should also get buy-in from Robin since we also don't want to fork develoment or have to keep the two in sync. -Barry