Nico Kadel-Garcia writes: > On Thu, Jan 16, 2020 at 10:53 PM Jerry James <loganjerry@xxxxxxxxx> wrote: > > > > On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia <nkadel@xxxxxxxxx> 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@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
