Incorporating bsddb3

[Since the last message triggered no response, I'm retrying.] I have changes in my sandbox to incorporate bsddb3 into Python proper. This essentially is a copy of bsddb3 3.4.0, with the following modifications: - the extension module is called _bsddb (not bsddb3._db) - the package is called bsddb (not bsddb3) Both test_bsddb and test_anydbm continue to work unmodified. Is it ok to commit these changes? Regards, Martin

What happens if you don't have the software installed to make this work, but you do have what it takes to make the *old* bsddb module work? I presume that one bites the dust now? --Guido van Rossum (home page: http://www.python.org/~guido/)

Perhaps it could be made into an alternative for _bsddb to make that simpler (someone could even contribute code to let setup.py decide). What's the license on the bsddb3 Python extension? What's the license on the BerkeleyDB code from Sleepycat? Can we legally distribute RPMs or other binaries containing it? (I thought there were some restrictions that make it not open source.) --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum <guido@python.org> writes:
Perhaps it could be made into an alternative for _bsddb to make that simpler (someone could even contribute code to let setup.py decide).
Sure.
What's the license on the bsddb3 Python extension?
See below.
What's the license on the BerkeleyDB code from Sleepycat?
There are two licenses: One that they call the "open source license", see http://www.sleepycat.com/license.net There is also a commercial license.
Can we legally distribute RPMs or other binaries containing it? (I thought there were some restrictions that make it not open source.)
It depends. This is the condition: # Redistributions in any form must be accompanied by information on # how to obtain complete source code for the DB software and any # accompanying software that uses the DB software. The source code # must either be included in the distribution or be available for no # more than the cost of distribution plus a nominal fee, and must be # freely redistributable under reasonable conditions. So distributing Python itself should be no problem. It appears that the Pythonlabs distribution still uses DB 1.85. Don't tell that Skip :-) He believes that this version has serious flaws that can lead to data corruption... Regards, Martin

martin@v.loewis.de (Martin v. Loewis) writes:
See below.
Actually, look here. /*---------------------------------------------------------------------- Copyright (c) 1999-2001, Digital Creations, Fredericksburg, VA, USA and Andrew Kuchling. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions, and the disclaimer that follows. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Digital Creations nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS AND CONTRIBUTORS *AS IS* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DIGITAL CREATIONS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ------------------------------------------------------------------------*/ It's all yours :-) Regards, Martin

Copyright (c) 1999-2001, Digital Creations, Fredericksburg, VA, USA and Andrew Kuchling. All rights reserved.
Now I'm confused. I thought this was Robun Dunn's bsddb3 module? Is there another? --Guido van Rossum (home page: http://www.python.org/~guido/)

"GvR" == Guido van Rossum <guido@python.org> writes:
>> Copyright (c) 1999-2001, Digital Creations, Fredericksburg, VA, >> USA and Andrew Kuchling. All rights reserved. GvR> Now I'm confused. I thought this was Robun Dunn's bsddb3 GvR> module? Is there another? ZC paid Robin to develop bsddb3. Early on when we were developing the Berkeley storages for ZODB, we specifically asked Sleepycat about redistribution and they said that there would be no legal problem to us redistributing source or binaries with Python, because Python is also open source. I wouldn't take my word for that though -- I'd want to get that in writing -- if we decided to distribute the library. I'm not sure we'd want to distribute either the source or binary though. They're fairly large. If we did, I'd recommend BerkeleyDB 4.0.14, not the latest version, because bsddb3 doesn't yet build on 4.1.24 because of some incompatible API changes, IIUC. Note that bsddb3's Windows distro comes with the BerkeleyDB dll's, I beleive. Martin, what do you plan to do about the pybsddb test suite? It's also fairly large. If you do add that, I'd suggest not running it by default, but only with a -resource flag. Then there's the documentation and project management issues to talk about. Maybe we include none of that, but simply "import" the code into Python and re-sync whenever it's appropriate. -Barry

barry@python.org (Barry A. Warsaw) writes:
libdb33.dll is 470k, which might be acceptable. I agree that distributing the source is pointless.
Martin, what do you plan to do about the pybsddb test suite?
I would ignore it, or put it in non-dist (in case this indicates the end of the pybsddb project).
Maybe we include none of that, but simply "import" the code into Python and re-sync whenever it's appropriate.
That is my proposal. Initially, there would be no user-visible change, as it would operate in compatible mode. We could then incorporate more documentation as we go along. Regards, Martin

It's similar to GPL's "copyleft". I think it's no different from what we do with e.g. GNU readline, so I think it's okay. Redistributors of Python in binary form will have to beware though. I wonder if we're on thin ice with the RPMs (since we don't clarify any of this)? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
... but we're not including readline in the standard Python distribution. Why would we want to include the database code itself in Python ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

Not in the source distro, but it will end up in the RPMs and other binary distros. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
But that would violate the Sleepycat license; we are not shipping readline or a module which statically links against readline in the binary distros for the same reason. As I understand, the BSD version shipped with Python so far is using a standard BSD style license, so there's no problem with it. However, Sleepycat added a copyleft kind of restriction to the BSD license which makes this troublesome, esp. since the restriction is not at all clear about what "use of the DB software" really means. Their web-page on this is: http://www.sleepycat.com/licensing.html Also, the Sleepycat license is not compatible with the Python license in the sense that the Python license is far less restrictive than the Sleepycat one. We'd have to make it very clear that we have integrated third-party code into the archive which falls under a much more restrictive license. (FWIW, It would actually be wise to summarize all the different licenses in the Python distro somewhere...) So back to my original question: why go through all these troubles ? BTW, Sleepycat ships Berkley DB 4.1, wouldn't it be wise to update the wrapper module to that version ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

"MAL" == M <mal@lemburg.com> writes:
>> Not in the source distro, but it will end up in the RPMs and >> other binary distros. MAL> But that would violate the Sleepycat license; we are not MAL> shipping readline or a module which statically links against MAL> readline in the binary distros for the same reason. Again, when we talked to Sleepycat a year and a half ago, they said it would be ok to distribute the library with Python. IIRC, even a binary distro would be fine. But I think a simple email to them would clear the issue up. MAL> BTW, Sleepycat ships Berkley DB 4.1, wouldn't it be wise to MAL> update the wrapper module to that version ? Because there are problems: http://sourceforge.net/mailarchive/forum.php?thread_id=1206938&forum_id=4362 -Barry

It only violates the Sleepycat license if (a) we don't include that license with the RPM or (b) we include closed-source code in that RPM. We're violating only (a) AFAIK and that's easily fixed.
We're not planning to incorporate Sleepycat code in the python source distribution. But if setup.py builds bsddb if it finds the parts, it's hard to keep the Sleepycat binaries in the RPMs. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Ok.
It's not like it's impossible, though :-). Ideal would be to have the Python module link against the shared lib of the Sleepycat DB (if that's possible). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

[Apologies for any dupes: I'm trying to repost this with one CC header to see if that fixes a problem Guido was seeing -BAW]
"MAL" == M <mal@lemburg.com> writes:
>> Not in the source distro, but it will end up in the RPMs and >> other binary distros. MAL> But that would violate the Sleepycat license; we are not MAL> shipping readline or a module which statically links against MAL> readline in the binary distros for the same reason. Again, when we talked to Sleepycat a year and a half ago, they said it would be ok to distribute the library with Python. IIRC, even a binary distro would be fine. But I think a simple email to them would clear the issue up. MAL> BTW, Sleepycat ships Berkley DB 4.1, wouldn't it be wise to MAL> update the wrapper module to that version ? Because there are problems: http://sourceforge.net/mailarchive/forum.php?thread_id=1206938&forum_id=4362 -Barry

Martin> I have changes in my sandbox to incorporate bsddb3 into Python Martin> proper.... Martin> Both test_bsddb and test_anydbm continue to work unmodified. Martin> Is it ok to commit these changes? I say go for it. Better now, when it's easily backed out than later. I use bsddb pretty frequently, and run Python CVS on my development machine, so I'll be able to wring it out a bit. Skip

Skip Montanaro <skip@pobox.com> writes:
Thanks for the encouragement. I really need PythonLab's permission here, though, since it will affect what the Windows distribution contains. If the political issues can be settled, working out the build process for Windows should be easy. Regards, Martin

Barry will send an email to Sleepycat to ask exactly what the restrictions on binary redistribution are. There's also the issue of upgrading. Suppose someone has created a database using bsddb in Python 2.2. When they upgrade to Python 2.3, they'll get an exception when they open the database, because Sleepycat DB 4.x can't open BSD DB 1.85 databases. What do we tell them to do? --Guido van Rossum (home page: http://www.python.org/~guido/)

"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> There's also the issue of upgrading. Suppose someone has GvR> created a database using bsddb in Python 2.2. When they GvR> upgrade to Python 2.3, they'll get an exception when they GvR> open the database, because Sleepycat DB 4.x can't open BSD DB GvR> 1.85 databases. What do we tell them to do? Run this script: http://www.sleepycat.com/docs/utility/db_upgrade.html -Barry

Guido> When they upgrade to Python 2.3, they'll get an exception when Guido> they open the database, because Sleepycat DB 4.x can't open BSD Guido> DB 1.85 databases. What do we tell them to do? The same thing you've had to tell them in the past. Use the tools Sleepycat provides (db_dump, db_load, etc) to update databases from old file formats to new ones. Skip

Guido van Rossum <guido@python.org> writes:
Whether this happens somewhat depends on the system. On Linux, it won't happen, since people likely have been using Sleepycat DB, anyway, through db_185.h. If they really use DB 1.85 (i.e. on Windows), they need to use db_dump/db_load. Regards, Martin

"MvL" == Martin v Loewis <martin@v.loewis.de> writes:
>> There's also the issue of upgrading. Suppose someone has >> created a database using bsddb in Python 2.2. When they >> upgrade to Python 2.3, they'll get an exception when they open >> the database, because Sleepycat DB 4.x can't open BSD DB 1.85 >> databases. What do we tell them to do? MvL> Whether this happens somewhat depends on the system. On MvL> Linux, it won't happen, since people likely have been using MvL> Sleepycat DB, anyway, through db_185.h. Also note that just because they used the 1.85 version of the API doesn't necessarily mean they've got a 1.85 version of the database file format. They could be using a newer version of the library in 1.85-compat mode. -Barry

"MvL" == Martin v Loewis <martin@v.loewis.de> writes:
MvL> If the political issues can be settled, working out the build MvL> process for Windows should be easy. I'm going to contact Sleepycat and start a dialog with them on the licensing and binary redist issues. I'll Cc Guido so we'll get a definitive answer on that, hopefully soon. -Barry

What happens if you don't have the software installed to make this work, but you do have what it takes to make the *old* bsddb module work? I presume that one bites the dust now? --Guido van Rossum (home page: http://www.python.org/~guido/)

Perhaps it could be made into an alternative for _bsddb to make that simpler (someone could even contribute code to let setup.py decide). What's the license on the bsddb3 Python extension? What's the license on the BerkeleyDB code from Sleepycat? Can we legally distribute RPMs or other binaries containing it? (I thought there were some restrictions that make it not open source.) --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum <guido@python.org> writes:
Perhaps it could be made into an alternative for _bsddb to make that simpler (someone could even contribute code to let setup.py decide).
Sure.
What's the license on the bsddb3 Python extension?
See below.
What's the license on the BerkeleyDB code from Sleepycat?
There are two licenses: One that they call the "open source license", see http://www.sleepycat.com/license.net There is also a commercial license.
Can we legally distribute RPMs or other binaries containing it? (I thought there were some restrictions that make it not open source.)
It depends. This is the condition: # Redistributions in any form must be accompanied by information on # how to obtain complete source code for the DB software and any # accompanying software that uses the DB software. The source code # must either be included in the distribution or be available for no # more than the cost of distribution plus a nominal fee, and must be # freely redistributable under reasonable conditions. So distributing Python itself should be no problem. It appears that the Pythonlabs distribution still uses DB 1.85. Don't tell that Skip :-) He believes that this version has serious flaws that can lead to data corruption... Regards, Martin

martin@v.loewis.de (Martin v. Loewis) writes:
See below.
Actually, look here. /*---------------------------------------------------------------------- Copyright (c) 1999-2001, Digital Creations, Fredericksburg, VA, USA and Andrew Kuchling. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions, and the disclaimer that follows. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Digital Creations nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS AND CONTRIBUTORS *AS IS* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DIGITAL CREATIONS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ------------------------------------------------------------------------*/ It's all yours :-) Regards, Martin

Copyright (c) 1999-2001, Digital Creations, Fredericksburg, VA, USA and Andrew Kuchling. All rights reserved.
Now I'm confused. I thought this was Robun Dunn's bsddb3 module? Is there another? --Guido van Rossum (home page: http://www.python.org/~guido/)

"GvR" == Guido van Rossum <guido@python.org> writes:
>> Copyright (c) 1999-2001, Digital Creations, Fredericksburg, VA, >> USA and Andrew Kuchling. All rights reserved. GvR> Now I'm confused. I thought this was Robun Dunn's bsddb3 GvR> module? Is there another? ZC paid Robin to develop bsddb3. Early on when we were developing the Berkeley storages for ZODB, we specifically asked Sleepycat about redistribution and they said that there would be no legal problem to us redistributing source or binaries with Python, because Python is also open source. I wouldn't take my word for that though -- I'd want to get that in writing -- if we decided to distribute the library. I'm not sure we'd want to distribute either the source or binary though. They're fairly large. If we did, I'd recommend BerkeleyDB 4.0.14, not the latest version, because bsddb3 doesn't yet build on 4.1.24 because of some incompatible API changes, IIUC. Note that bsddb3's Windows distro comes with the BerkeleyDB dll's, I beleive. Martin, what do you plan to do about the pybsddb test suite? It's also fairly large. If you do add that, I'd suggest not running it by default, but only with a -resource flag. Then there's the documentation and project management issues to talk about. Maybe we include none of that, but simply "import" the code into Python and re-sync whenever it's appropriate. -Barry

barry@python.org (Barry A. Warsaw) writes:
libdb33.dll is 470k, which might be acceptable. I agree that distributing the source is pointless.
Martin, what do you plan to do about the pybsddb test suite?
I would ignore it, or put it in non-dist (in case this indicates the end of the pybsddb project).
Maybe we include none of that, but simply "import" the code into Python and re-sync whenever it's appropriate.
That is my proposal. Initially, there would be no user-visible change, as it would operate in compatible mode. We could then incorporate more documentation as we go along. Regards, Martin

It's similar to GPL's "copyleft". I think it's no different from what we do with e.g. GNU readline, so I think it's okay. Redistributors of Python in binary form will have to beware though. I wonder if we're on thin ice with the RPMs (since we don't clarify any of this)? --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
... but we're not including readline in the standard Python distribution. Why would we want to include the database code itself in Python ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

Not in the source distro, but it will end up in the RPMs and other binary distros. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
But that would violate the Sleepycat license; we are not shipping readline or a module which statically links against readline in the binary distros for the same reason. As I understand, the BSD version shipped with Python so far is using a standard BSD style license, so there's no problem with it. However, Sleepycat added a copyleft kind of restriction to the BSD license which makes this troublesome, esp. since the restriction is not at all clear about what "use of the DB software" really means. Their web-page on this is: http://www.sleepycat.com/licensing.html Also, the Sleepycat license is not compatible with the Python license in the sense that the Python license is far less restrictive than the Sleepycat one. We'd have to make it very clear that we have integrated third-party code into the archive which falls under a much more restrictive license. (FWIW, It would actually be wise to summarize all the different licenses in the Python distro somewhere...) So back to my original question: why go through all these troubles ? BTW, Sleepycat ships Berkley DB 4.1, wouldn't it be wise to update the wrapper module to that version ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

"MAL" == M <mal@lemburg.com> writes:
>> Not in the source distro, but it will end up in the RPMs and >> other binary distros. MAL> But that would violate the Sleepycat license; we are not MAL> shipping readline or a module which statically links against MAL> readline in the binary distros for the same reason. Again, when we talked to Sleepycat a year and a half ago, they said it would be ok to distribute the library with Python. IIRC, even a binary distro would be fine. But I think a simple email to them would clear the issue up. MAL> BTW, Sleepycat ships Berkley DB 4.1, wouldn't it be wise to MAL> update the wrapper module to that version ? Because there are problems: http://sourceforge.net/mailarchive/forum.php?thread_id=1206938&forum_id=4362 -Barry

It only violates the Sleepycat license if (a) we don't include that license with the RPM or (b) we include closed-source code in that RPM. We're violating only (a) AFAIK and that's easily fixed.
We're not planning to incorporate Sleepycat code in the python source distribution. But if setup.py builds bsddb if it finds the parts, it's hard to keep the Sleepycat binaries in the RPMs. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:
Ok.
It's not like it's impossible, though :-). Ideal would be to have the Python module link against the shared lib of the Sleepycat DB (if that's possible). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

[Apologies for any dupes: I'm trying to repost this with one CC header to see if that fixes a problem Guido was seeing -BAW]
"MAL" == M <mal@lemburg.com> writes:
>> Not in the source distro, but it will end up in the RPMs and >> other binary distros. MAL> But that would violate the Sleepycat license; we are not MAL> shipping readline or a module which statically links against MAL> readline in the binary distros for the same reason. Again, when we talked to Sleepycat a year and a half ago, they said it would be ok to distribute the library with Python. IIRC, even a binary distro would be fine. But I think a simple email to them would clear the issue up. MAL> BTW, Sleepycat ships Berkley DB 4.1, wouldn't it be wise to MAL> update the wrapper module to that version ? Because there are problems: http://sourceforge.net/mailarchive/forum.php?thread_id=1206938&forum_id=4362 -Barry

Martin> I have changes in my sandbox to incorporate bsddb3 into Python Martin> proper.... Martin> Both test_bsddb and test_anydbm continue to work unmodified. Martin> Is it ok to commit these changes? I say go for it. Better now, when it's easily backed out than later. I use bsddb pretty frequently, and run Python CVS on my development machine, so I'll be able to wring it out a bit. Skip

Skip Montanaro <skip@pobox.com> writes:
Thanks for the encouragement. I really need PythonLab's permission here, though, since it will affect what the Windows distribution contains. If the political issues can be settled, working out the build process for Windows should be easy. Regards, Martin

Barry will send an email to Sleepycat to ask exactly what the restrictions on binary redistribution are. There's also the issue of upgrading. Suppose someone has created a database using bsddb in Python 2.2. When they upgrade to Python 2.3, they'll get an exception when they open the database, because Sleepycat DB 4.x can't open BSD DB 1.85 databases. What do we tell them to do? --Guido van Rossum (home page: http://www.python.org/~guido/)

"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> There's also the issue of upgrading. Suppose someone has GvR> created a database using bsddb in Python 2.2. When they GvR> upgrade to Python 2.3, they'll get an exception when they GvR> open the database, because Sleepycat DB 4.x can't open BSD DB GvR> 1.85 databases. What do we tell them to do? Run this script: http://www.sleepycat.com/docs/utility/db_upgrade.html -Barry

Guido> When they upgrade to Python 2.3, they'll get an exception when Guido> they open the database, because Sleepycat DB 4.x can't open BSD Guido> DB 1.85 databases. What do we tell them to do? The same thing you've had to tell them in the past. Use the tools Sleepycat provides (db_dump, db_load, etc) to update databases from old file formats to new ones. Skip

Guido van Rossum <guido@python.org> writes:
Whether this happens somewhat depends on the system. On Linux, it won't happen, since people likely have been using Sleepycat DB, anyway, through db_185.h. If they really use DB 1.85 (i.e. on Windows), they need to use db_dump/db_load. Regards, Martin

"MvL" == Martin v Loewis <martin@v.loewis.de> writes:
>> There's also the issue of upgrading. Suppose someone has >> created a database using bsddb in Python 2.2. When they >> upgrade to Python 2.3, they'll get an exception when they open >> the database, because Sleepycat DB 4.x can't open BSD DB 1.85 >> databases. What do we tell them to do? MvL> Whether this happens somewhat depends on the system. On MvL> Linux, it won't happen, since people likely have been using MvL> Sleepycat DB, anyway, through db_185.h. Also note that just because they used the 1.85 version of the API doesn't necessarily mean they've got a 1.85 version of the database file format. They could be using a newer version of the library in 1.85-compat mode. -Barry

"MvL" == Martin v Loewis <martin@v.loewis.de> writes:
MvL> If the political issues can be settled, working out the build MvL> process for Windows should be easy. I'm going to contact Sleepycat and start a dialog with them on the licensing and binary redist issues. I'll Cc Guido so we'll get a definitive answer on that, hopefully soon. -Barry
participants (5)
-
barry@python.org
-
Guido van Rossum
-
M.-A. Lemburg
-
martin@v.loewis.de
-
Skip Montanaro