Re: Effort to remove libdb
On Mon, 20 Jan 2020 at 03:59, Panu Matilainen wrote: > > On 1/17/20 3:03 PM, Stephen John Smoogen wrote: > > On Fri, 17 Jan 2020 at 01:16, Chris Adams wrote: > >> > >> Once upon a time, Nico Kadel-Garcia said: > >>> Is there any software or service that currently uses Berkeley DB that > >>> cannot reasonably be discarded and rebuilt from scratch for new > >>> versions of that software, without Berkeley DB entirely, as part of a > >>> Fedora release? > >> > > > >> BDB is kind of a part of the collective history of Unix systems and > >> assumed to always be available. Is there nobody interested in > >> maintaining the final license-compatible version in a pure bugfix mode? > >> Does it get that many bugs? > > > > It does get some and most of them are gnarly ones where if you fix > > that bug you have now introduced a whole new class of bugs for some > > other set of users. There are 30 years of software which expect BDB to > > work like it was when the program was originally written. You need to > > be an archaeologist of knowing how BDB acted in 1994 to 2019 with all > > the little tweaks and changes which have happened during that. You > > also have to 'add' new features because someone is going to write some > > new language or coding paradigm which needs changes. > > > > I would expect keeping this up would require a full time company of > > programmers and equipment to build all the test cases that would be > > needed to try and support this. > > > > Yup. I guess many projects relying on BDB have been in a denial over > this. 6.5 years of waiting for "surely somebody will pick up the pieces" > hasn't changed the situation a whole lot: everybody needs it but nobody > wants it. > It also goes with the other item.. If it isn't broke (for me).. why fix it (for others). Most people really aren't going to care about the licenses and they probably aren't going to end up in the corner cases which need fixing by whoever takes up the code... until some sort of security review finds that they do.. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On 1/17/20 3:03 PM, Stephen John Smoogen wrote: On Fri, 17 Jan 2020 at 01:16, Chris Adams wrote: Once upon a time, Nico Kadel-Garcia said: Is there any software or service that currently uses Berkeley DB that cannot reasonably be discarded and rebuilt from scratch for new versions of that software, without Berkeley DB entirely, as part of a Fedora release? BDB is kind of a part of the collective history of Unix systems and assumed to always be available. Is there nobody interested in maintaining the final license-compatible version in a pure bugfix mode? Does it get that many bugs? It does get some and most of them are gnarly ones where if you fix that bug you have now introduced a whole new class of bugs for some other set of users. There are 30 years of software which expect BDB to work like it was when the program was originally written. You need to be an archaeologist of knowing how BDB acted in 1994 to 2019 with all the little tweaks and changes which have happened during that. You also have to 'add' new features because someone is going to write some new language or coding paradigm which needs changes. I would expect keeping this up would require a full time company of programmers and equipment to build all the test cases that would be needed to try and support this. Yup. I guess many projects relying on BDB have been in a denial over this. 6.5 years of waiting for "surely somebody will pick up the pieces" hasn't changed the situation a whole lot: everybody needs it but nobody wants it. - Panu - ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Fri, 17 Jan 2020 at 01:16, Chris Adams wrote: > > Once upon a time, Nico Kadel-Garcia said: > > Is there any software or service that currently uses Berkeley DB that > > cannot reasonably be discarded and rebuilt from scratch for new > > versions of that software, without Berkeley DB entirely, as part of a > > Fedora release? > > BDB is kind of a part of the collective history of Unix systems and > assumed to always be available. Is there nobody interested in > maintaining the final license-compatible version in a pure bugfix mode? > Does it get that many bugs? It does get some and most of them are gnarly ones where if you fix that bug you have now introduced a whole new class of bugs for some other set of users. There are 30 years of software which expect BDB to work like it was when the program was originally written. You need to be an archaeologist of knowing how BDB acted in 1994 to 2019 with all the little tweaks and changes which have happened during that. You also have to 'add' new features because someone is going to write some new language or coding paradigm which needs changes. I would expect keeping this up would require a full time company of programmers and equipment to build all the test cases that would be needed to try and support this. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
Le jeudi 16 janvier 2020 à 20:52 -0700, Jerry James a écrit : > On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia > wrote: > > The lack of a good backup tool for Berkeley DB earned me nearly a > > year > > of contracting salary from the BBC to keep alive an obsolete > > Berkeley > > DB and Apache 1.3 on RHEL systems long after httpd 2.x was > > released. > > It was discarded by Subversion with good cause. > > > > Why does XEmacs need to preserve a database? > > It may not. XEmacs provides a generic "database" interface in Emacs > Lisp. The underlying database can be libdb, gdbm, ndbm, and probably > something else I've forgotten. XEmacs itself only uses that > interface to keep a Unicode code point database. That is easily > recreated. Just port xemacs to Harfbuzz, fontconfig and the rest of the freedesktop text stack. That will solve this issue and many others. Regards, -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
Ah, it permits linking only with GPLv3!!! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
Sorry if I misunderstood, but I thought BDB was licensed under the GNU AFFERO GENERAL PUBLIC LICENSE v3 [1]. Is that not correct? Ciao Guido [1]: https://www.oracle.com/downloads/licenses/berkeleydb-oslicense.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
Nico Kadel-Garcia writes: > On Thu, Jan 16, 2020 at 10:53 PM Jerry James wrote: > > > > On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia wrote: > > > The lack of a good backup tool for Berkeley DB earned me nearly a year > > > of contracting salary from the BBC to keep alive an obsolete Berkeley > > > DB and Apache 1.3 on RHEL systems long after httpd 2.x was released. > > > It was discarded by Subversion with good cause. > > > > > > Why does XEmacs need to preserve a database? > > > > It may not. XEmacs provides a generic "database" interface in Emacs > > Lisp. The underlying database can be libdb, gdbm, ndbm, and probably > > something else I've forgotten. XEmacs itself only uses that interface > > to keep a Unicode code point database. That is easily recreated. As Jerry points out, XEmacs doesn't. Its users do. For example, the VM mail client can optionally use a db-style database to index mail folders, with substantial speedup, especially on very large folders (which the VM UI encourages). In the case of VM, this is trivially worked around in a few seconds -- just blow away the db file, and let VM reindex. I hope VM would respond gracefully (though with a perceptible performance degradation but) with no loss of functionality to removal of libdb, but it might also fatally error if it tried to use libdb but it wasn't there, requiring manual reconfiguration to use an alternative backend. I can't say the same for other (possible) use cases, since it's a feature of (X)Emacs Lisp. (X)Emacs Lisp has been used to build thousands of applications, most of which have persistent data of some kind, and more than a few of which have persistent data that could be kept in a libdb database. > > The problem is that I have no way of knowing what people have done > > with the Lisp interface, what databases they may have created. Exactly. > > It is entirely possible that 0 people will be impacted if I > > change the builds to use gdbm instead. I think that very unlikely, since the use of a specific backend is explicitly configured. People will notice if they've been using libdb when support is removed. > Is there any software or service that currently uses Berkeley DB that > cannot reasonably be discarded and rebuilt from scratch for new > versions of that software, without Berkeley DB entirely, as part of a > Fedora release? Of course you can do that as long as you're willing to raise a big hairy middle finger to an unknown number of users. The point of a database is persistence. Users do not expect databases to suddenly become useless; they expect a migration path, preferably seamless and in the background. Regards, Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Fri, Jan 17, 2020 at 12:29:54AM -0500, Nico Kadel-Garcia wrote: > Is there any software or service that currently uses Berkeley DB that > cannot reasonably be discarded and rebuilt from scratch for new > versions of that software, without Berkeley DB entirely, as part of a > Fedora release? E.g. pam_abl collects login failures and successes from the PAM sessions to a BDB file. There is no way of rebuildnig the database because the data source are events in a live system. But losing the database is not a big deal as the data are typically only helpful for a few hours. A bigger issue is that e.g. pam_abl only supports BDB. There is no backend for other databases. I worry there will be a lot of packages like this. I recommend to keep the latest license-acceptible BDB in Fedora, schedule a removal of it for a reasonably future Fedora release and file bugs against all the packages using it that they need to migrate from BDB until then. This gives maintainer and upsreams enough time for migration from BDB. Then the remaining packages will be dropped from Fedora as a regular fails to build cleanup. I think a similar approach was used when uprading OpenSSL to 1.1.1 version. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
Once upon a time, Nico Kadel-Garcia said: > Is there any software or service that currently uses Berkeley DB that > cannot reasonably be discarded and rebuilt from scratch for new > versions of that software, without Berkeley DB entirely, as part of a > Fedora release? One problem is the upgrade path - there's no way to know all the things that are currently stored in BDB files, and once upgraded, there's not going to be a way to get the data out. Some BDBs are built from other data files (and can be rebuilt, although there's no way to know all the things and trigger such rebuilds automatically), but some are directly edited. Part of the attraction of BDB files was that they could be easily updated from programs/scripts for use by other programs/scripts. postfix and sendmail both use BDB files for maps. IIRC sendmail just supports a single map database library at a time, configured at build time (can be GDBM or BDB). postfix supports some alternates, but BDB is considered the standard (and changing to anything else requires modifying configuration before rebuilding maps). I think exim is similar (I'm just not as familiar with it). Not all things that use BDB even support alternates (or dump and restore of data files), for example arpd from iproute. Also, since the scripting languages (python/php/perl) have supported it as a service-free simple DB, there's going to be an unknown number of scripts that use it that aren't packaged as part of the distribution. BDB is kind of a part of the collective history of Unix systems and assumed to always be available. Is there nobody interested in maintaining the final license-compatible version in a pure bugfix mode? Does it get that many bugs? -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Thu, Jan 16, 2020 at 10:53 PM Jerry James wrote: > > On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia wrote: > > The lack of a good backup tool for Berkeley DB earned me nearly a year > > of contracting salary from the BBC to keep alive an obsolete Berkeley > > DB and Apache 1.3 on RHEL systems long after httpd 2.x was released. > > It was discarded by Subversion with good cause. > > > > Why does XEmacs need to preserve a database? > > It may not. XEmacs provides a generic "database" interface in Emacs > Lisp. The underlying database can be libdb, gdbm, ndbm, and probably > something else I've forgotten. XEmacs itself only uses that interface > to keep a Unicode code point database. That is easily recreated. > > The problem is that I have no way of knowing what people have done > with the Lisp interface, what databases they may have created. It is > entirely possible that 0 people will be impacted if I change the > builds to use gdbm instead. It is also possible that I will get lots > of bugs filed by angry people who can't access their databases > anymore. I have no way to tell (without actually doing it and seeing > how many bugs get filed, of course). > > > Is there anything that couldn't expect a rebuild as part an OS > > release? Anything that people actually use, besides XEmacs? > > Sorry, I'm not catching your meaning here. Is there any software or service that currently uses Berkeley DB that cannot reasonably be discarded and rebuilt from scratch for new versions of that software, without Berkeley DB entirely, as part of a Fedora release? Subversion used to provide it for compatibility, but it's been so long I think we could reasonable leave Berkeley DB entirely out of it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia wrote: > The lack of a good backup tool for Berkeley DB earned me nearly a year > of contracting salary from the BBC to keep alive an obsolete Berkeley > DB and Apache 1.3 on RHEL systems long after httpd 2.x was released. > It was discarded by Subversion with good cause. > > Why does XEmacs need to preserve a database? It may not. XEmacs provides a generic "database" interface in Emacs Lisp. The underlying database can be libdb, gdbm, ndbm, and probably something else I've forgotten. XEmacs itself only uses that interface to keep a Unicode code point database. That is easily recreated. The problem is that I have no way of knowing what people have done with the Lisp interface, what databases they may have created. It is entirely possible that 0 people will be impacted if I change the builds to use gdbm instead. It is also possible that I will get lots of bugs filed by angry people who can't access their databases anymore. I have no way to tell (without actually doing it and seeing how many bugs get filed, of course). > Is there anything that couldn't expect a rebuild as part an OS > release? Anything that people actually use, besides XEmacs? Sorry, I'm not catching your meaning here. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Thu, Jan 16, 2020 at 1:17 PM Jerry James wrote: > > On Thu, Jan 16, 2020 at 9:09 AM Filip Janus 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. The lack of a good backup tool for Berkeley DB earned me nearly a year of contracting salary from the BBC to keep alive an obsolete Berkeley DB and Apache 1.3 on RHEL systems long after httpd 2.x was released. It was discarded by Subversion with good cause. Why does XEmacs need to preserve a database? > 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. Is there anything that couldn't expect a rebuild as part an OS release? Anything that people actually use, besides XEmacs? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
Would it be possible to have a libdb-compat package with the 5.x version to at least decouple the packages that are somewhat stuck with that version of libdb and the ones that can use newer version? I still need to figure out how sasl can switch databases, the problem is that I do not want to trash users setup by invalidating their saslauthdb databases, at the same time I see no easy way to migrate them as those db could be anywhere on the system. However I could potential try and ondemand upgrade if libdb were still available (via libdb-compat) for releases (to catch upgrades that skip a release) so that the database could be read and then rewritten back in the new format at first use. Note I do not know if even this plan is feasible, but wanted to know if I should even try to feigure out or if libdb-compat is an impossibility. Simo. On Thu, 2020-01-16 at 17:08 +0100, Filip Janus 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. > > > [1] > https://fedoraproject.org/w/index.php?title=User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora=User%3AJstanek%2FDraft_-_Removing_BerkeleyDB_from_Fedora > > Fiip Januš - Red Hat Associate Developer Engineer - Databases Team > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Thu, 16 Jan 2020 at 15:42, Stephen John Smoogen wrote: > > On Thu, 16 Jan 2020 at 14:57, Mark Reynolds wrote: > > > > > > On 1/16/20 2:38 PM, Stephen John Smoogen wrote: > > > On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: > > >> 389 Directory Server (389-ds-base), aka Red Hat Directory Server, is > > >> dependent on libdb. We are currently working towards moving to LMDB, > > >> but that work is probably a year away from being fully complete. We are > > >> hoping/planning to have it done for the next major release of RHEL. I > > >> would hope libdb is not pulled out from underneath us before we can make > > >> the transition to LMDB. > > >> > > > Going from the release dates, Fedora 33 is going to be where the next > > > RHEL is branched. > > Isn't that for RHEL 8.4? I was referring to the next MAJOR release of > > RHEL :-) Either way, I still estimate it could still take up to a year > > I sent an internal email for your enjoyment :/ > And this is where i find that I was not sending email to the person directly but the list. Thank you folks.. its been a great thirty years but I need to go back to remedial email classes. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On 1/16/20 3:42 PM, Stephen John Smoogen wrote: On Thu, 16 Jan 2020 at 14:57, Mark Reynolds wrote: On 1/16/20 2:38 PM, Stephen John Smoogen wrote: On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: 389 Directory Server (389-ds-base), aka Red Hat Directory Server, is dependent on libdb. We are currently working towards moving to LMDB, but that work is probably a year away from being fully complete. We are hoping/planning to have it done for the next major release of RHEL. I would hope libdb is not pulled out from underneath us before we can make the transition to LMDB. Going from the release dates, Fedora 33 is going to be where the next RHEL is branched. Isn't that for RHEL 8.4? I was referring to the next MAJOR release of RHEL :-) Either way, I still estimate it could still take up to a year I sent an internal email for your enjoyment :/ Ah yes, I stand corrected on the F33 schedule, thank you for the offline clarification! Well we will not be ready by F33, hopefully F35... to get fully switched over to LMDB with our current team resources :-/ Mark On 1/16/20 11:08 AM, Filip Janus wrote: -- 389 Directory Server Development Team -- 389 Directory Server Development Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Thu, 16 Jan 2020 at 14:57, Mark Reynolds wrote: > > > On 1/16/20 2:38 PM, Stephen John Smoogen wrote: > > On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: > >> 389 Directory Server (389-ds-base), aka Red Hat Directory Server, is > >> dependent on libdb. We are currently working towards moving to LMDB, but > >> that work is probably a year away from being fully complete. We are > >> hoping/planning to have it done for the next major release of RHEL. I > >> would hope libdb is not pulled out from underneath us before we can make > >> the transition to LMDB. > >> > > Going from the release dates, Fedora 33 is going to be where the next > > RHEL is branched. > Isn't that for RHEL 8.4? I was referring to the next MAJOR release of > RHEL :-) Either way, I still estimate it could still take up to a year I sent an internal email for your enjoyment :/ > to get fully switched over to LMDB with our current team resources :-/ > > > >> Mark > >> > >> On 1/16/20 11:08 AM, Filip Janus wrote: > >> > > > -- > > 389 Directory Server Development Team > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On 1/16/20 2:38 PM, Stephen John Smoogen wrote: On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: 389 Directory Server (389-ds-base), aka Red Hat Directory Server, is dependent on libdb. We are currently working towards moving to LMDB, but that work is probably a year away from being fully complete. We are hoping/planning to have it done for the next major release of RHEL. I would hope libdb is not pulled out from underneath us before we can make the transition to LMDB. Going from the release dates, Fedora 33 is going to be where the next RHEL is branched. Isn't that for RHEL 8.4? I was referring to the next MAJOR release of RHEL :-) Either way, I still estimate it could still take up to a year to get fully switched over to LMDB with our current team resources :-/ Mark On 1/16/20 11:08 AM, Filip Janus wrote: -- 389 Directory Server Development Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: > > 389 Directory Server (389-ds-base), aka Red Hat Directory Server, is > dependent on libdb. We are currently working towards moving to LMDB, but > that work is probably a year away from being fully complete. We are > hoping/planning to have it done for the next major release of RHEL. I would > hope libdb is not pulled out from underneath us before we can make the > transition to LMDB. > Going from the release dates, Fedora 33 is going to be where the next RHEL is branched. > Mark > > On 1/16/20 11:08 AM, Filip Janus wrote: > -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
389 Directory Server (389-ds-base), aka Red Hat Directory Server, is dependent on libdb. We are currently working towards moving to LMDB, but that work is probably a year away from being fully complete. We are hoping/planning to have it done for the next major release of RHEL. I would hope libdb is not pulled out from underneath us before we can make the transition to LMDB. Mark On 1/16/20 11:08 AM, Filip Janus 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. [1] https://fedoraproject.org/w/index.php?title=User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora=User%3AJstanek%2FDraft_-_Removing_BerkeleyDB_from_Fedora Fiip Januš - Red Hat Associate Developer Engineer - Databases Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org -- 389 Directory Server Development Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Thu, Jan 16, 2020 at 9:09 AM Filip Janus 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Effort to remove libdb
On Thu, Jan 16, 2020 at 11:09 AM Filip Janus 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. > > > [1] > https://fedoraproject.org/w/index.php?title=User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora=User%3AJstanek%2FDraft_-_Removing_BerkeleyDB_from_Fedora > I'm very much in support of a plan for this. In my opinion, the sooner the better. At least for RPM, I have personally been testing the non-BDB backends since they were introduced in various environments. I'm currently using the NDB backend for a couple of projects (POSIX stack for Windows, and a devtool stack for macOS), and have been testing the SQLite backend in rpm git master since it was introduced a few months ago in a Linux distribution. Also in the RPM case, support recently landed for reading BDB rpmdb without libdb for supporting inspecting and converting from a BDB rpmdb. So it's technically possible to do a conversion from bdb to something else without libdb being linked to it. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Effort to remove libdb
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. [1] https://fedoraproject.org/w/index.php?title=User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora=User%3AJstanek%2FDraft_-_Removing_BerkeleyDB_from_Fedora Fiip Januš - Red Hat Associate Developer Engineer - Databases Team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
