On Thu, Jan 16, 2020 at 9:09 AM Filip Janus <fjanus@xxxxxxxxxx> wrote: > Hi all, > as you maybe know the BerkeleyDB 6.x has a more restrictive license than the previous versions (AGPLv3 vs. LGPLv2), and due to that many projects cannot use it. > Few years ago there was an effort to reduce the number of dependent packages on BerkeleyDB(libdb). And nowadays situation seems to be almost the same. Here is > the link with packages dependent on libdb[1] from previous effort, which is truthful for nowadays situation. As a member of the database team which is responsible for libdb, I would like to know your opinions on this problem, because many components have many specific cases where is libdb used. > > Nowadays we would like to remove libdb from Fedora as soon as possible, in the best case from Fedora 33. But I am afraid, that it isn't real. > > I have discussed this issue with my colleagues and we propose an approach. We found that the biggest problem would occur in updating components from versions that support libdb to versions without this support. Here could arise problems of inconsistency. > > Our approach assumes to convert old libdb databases to other supported database format in each package related to this libdb issue. Result would be Fedora without libdb. > I know that this approach probably isn't perfect. > > Therefore I would like to ask for Your opinions, suggestions and every problem clarification. > Thank you very much for any help. I welcome every opinion. For the xemacs package, I can simply build with gdbm instead of libdb. The question is how to migrate XEmacs users' existing databases. Is there a tool to, say, convert the libdb dump format to the gdbm dump format, or otherwise convert the database? We don't necessarily need to run such a tool ourselves, so long as we note the need to run it in Fedora's release notes. Database support is optional in XEmacs, and is not used for anything terribly important, so if we have to just switch to gdbm and tell the users, "Sorry, your databases have to be recreated from scratch," it probably won't be the end of the world, but it would be nice if we could offer some kind of migration path. -- Jerry James http://www.jamezone.org/ _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
