ipv6calc and Berkeley DB
Hi everyone, with the license of Berkeley DB version 6 having changed to a more restrictive APGL license, which is legally incompatible with most of the projects currently using BDB, Fedora's long term goal is to get rid of BDB completely. As ipv6calc is one of the projects still dependent on BDB in Fedora, I would like to ask you about the status of BDB in the project. Do you currently have any plans to migrate to/provide compatibility with a different DB given the license change or will you be staying with an older BDB version for the time being? Petr Kubat
Hi Petr, thank you for bringing this up. Am 22.07.2016 um 08:06 schrieb Petr Kubat:
Hi everyone,
with the license of Berkeley DB version 6 having changed to a more restrictive APGL license, which is legally incompatible with most of the projects currently using BDB, Fedora's long term goal is to get rid of BDB completely. As ipv6calc is one of the projects still dependent on BDB in Fedora, I would like to ask you about the status of BDB in the project.
Do you currently have any plans to migrate to/provide compatibility with a different DB given the license change or will you be staying with an older BDB version for the time being?
I've choosen Berkeley DB sometime in the past to have a common working database layer covering - EL 5, EL 6, EL 7 and Fedora - ability to use Perl for DB generation while using DB inside a C programm - no special feature are used, means the C program is only reading the DB and the Perl program is only generating the DB => no need to update the program to use Berkeley DB version 6 If there are long term plans to remove Berkeley DB even version <= 5 completly from Fedora (and therefore also from upcoming EL) I have to change to a different database in the future but keeping compatibility for some time. => what are the plans here for future Fedora and EL versions (e.g. EL 8)? => which database do you recommend to use then, supported at least since EL 6 (as EL 5 will go EOSL next year) in C and Perl on same easy way? Regards, Peter
Hello Peter, thank you for the fast reply. On 07/23/2016 11:19 AM, Peter Bieringer wrote:
Hi Petr,
thank you for bringing this up.
I've choosen Berkeley DB sometime in the past to have a common working database layer covering - EL 5, EL 6, EL 7 and Fedora - ability to use Perl for DB generation while using DB inside a C programm - no special feature are used, means the C program is only reading the DB and the Perl program is only generating the DB
=> no need to update the program to use Berkeley DB version 6
If there are long term plans to remove Berkeley DB even version <= 5 completly from Fedora (and therefore also from upcoming EL) I have to change to a different database in the future but keeping compatibility for some time.
=> what are the plans here for future Fedora and EL versions (e.g. EL 8)?
The current plan is to remove Berkeley DB dependencies by the time EL8 hits. We might be keeping the Berkeley DB packages in EL8 for the sake of compatibility and for data migration tools however.
=> which database do you recommend to use then, supported at least since EL 6 (as EL 5 will go EOSL next year) in C and Perl on same easy way?
Regards, Peter
A lot of projects are changing (or planning to change) to LMDB [1][2] which was developed as a replacement of Berkeley DB for the OpenLDAP project and, from what I have seen of it, seems to have a similar C API to Berkeley DB. The caveat to this is that it is so far only available in Fedora and EPEL. As for perl there is a third party wrapper available [3] however I do not know how the API compares to current Berkeley DB wrappers. Another alternative is TokyoCabinet [4], which is available in EL6, EL7 and Fedora. The project however has been already succeeded by KyotoCabinet which has unfortunately the same EL availability as LMDB. [1] https://symas.com/products/lightning-memory-mapped-database/ [2] http://lmdb.tech/doc/index.html [3] https://metacpan.org/pod/LMDB_File [4] http://fallabs.com/tokyocabinet/ Petr
Hi Petr, Am 25.07.2016 um 08:45 schrieb Petr Kubat:
=> what are the plans here for future Fedora and EL versions (e.g. EL 8)?
The current plan is to remove Berkeley DB dependencies by the time EL8 hits. We might be keeping the Berkeley DB packages in EL8 for the sake of compatibility and for data migration tools however.
If I read your status regarding LMDB, TokyoCabinet, KyotoCabinet, I believe EL8 can't drop Berkeley DB completly, because there is no alternative database is currently in EL6 or EL6 vanilla available. And once EL8 would be released, EL6 is still under support, means software which should run on vanilla EL6+7+8 in compatible way has to use BerkeleyDB. Only chance would be to put LMDB in a later minor release to vanilla EL6+EL7 before EL8 will be released - are there plans for that? And TokyoCabinet already reached somehow it's EOSL by the maintainer...so also not a good candidate for the future. Opinions about use of SQLite instead of BerkeleyDB? Regards, Peter
Hello Peter, On 07/25/2016 09:30 PM, Peter Bieringer wrote:
Hi Petr,
Am 25.07.2016 um 08:45 schrieb Petr Kubat:
=> what are the plans here for future Fedora and EL versions (e.g. EL 8)? The current plan is to remove Berkeley DB dependencies by the time EL8 hits. We might be keeping the Berkeley DB packages in EL8 for the sake of compatibility and for data migration tools however. If I read your status regarding LMDB, TokyoCabinet, KyotoCabinet, I believe EL8 can't drop Berkeley DB completly, because there is no alternative database is currently in EL6 or EL6 vanilla available.
As touched in the previous email, Berkeley DB will not be dropped completely in EL8 given that we need it to provide the users with a means of migration to new formats.
And once EL8 would be released, EL6 is still under support, means software which should run on vanilla EL6+7+8 in compatible way has to use BerkeleyDB.
Only chance would be to put LMDB in a later minor release to vanilla EL6+EL7 before EL8 will be released - are there plans for that?
This will not happen for EL6 as it is entering production phase 2. For EL7, it is possible that the package will be included if needed. Both KyotoCabinet and LMDB are already present in EPEL6 and EPEL7 repos. Given that ipv6calc is located in Fedora and EPEL repos only, you should not have any problems with using either LMDB or KyotoCabinet for the alternative to BDB. Apart from the Perl wrappers not being packaged at the moment but that should be easy enough to fix.
And TokyoCabinet already reached somehow it's EOSL by the maintainer...so also not a good candidate for the future.
Opinions about use of SQLite instead of BerkeleyDB?
Unfortunately I am not familiar with the details of SQLite. However, given that it is a different type of a data store (relational vs. key-data pair) I would say that the migration to SQLite would be a bit more difficult.
Regards, Peter
Thanks, Petr
Hello Peter, For your information, I am working on a list of alternatives for Berkeley DB which can be found at: https://fedoraproject.org/wiki/User:Pkubat/BerkeleyDB_alternatives Please take a look if you are interested. Regards, Petr Kubat
Hi Petr, Am 01.08.2016 um 08:00 schrieb Petr Kubat:
Hello Peter,
For your information, I am working on a list of alternatives for Berkeley DB which can be found at:
https://fedoraproject.org/wiki/User:Pkubat/BerkeleyDB_alternatives
Please take a look if you are interested.
Great, thank you! I will probably switch to LMDB. Regards, Peter
Hi Petr, Am 01.08.2016 um 08:05 schrieb Peter Bieringer:
Hi Petr,
Am 01.08.2016 um 08:00 schrieb Petr Kubat:
Hello Peter,
For your information, I am working on a list of alternatives for Berkeley DB which can be found at:
https://fedoraproject.org/wiki/User:Pkubat/BerkeleyDB_alternatives
Please take a look if you are interested.
Great, thank you! I will probably switch to LMDB.
Just an update: investigated LMDB now deeper and found following: - perl-LMDB_File is (still) not available for FC24, had to rebuild http://www.openfusion.com.au/labs/srpms/perl-LMDB_File-0.09-1.of.el7.src.rpm => Perl database generation tool extended (that was the easy part...) - found that I haven't implemented an abstract database "product" layer in the past -> this requires a bunch of work because in addition I found that LMDB won't support BDB's "recno" and also I have a special BDB db handler cache implemented... => the support of (a) different database(s) would not be implemented in short time BTW: souces moved to GitHub now, but LMDB extenion branch is still private https://github.com/pbiering/ipv6calc Regards, Peter
participants (2)
-
Peter Bieringer
-
Petr Kubat