Nico Kadel-Garcia writes:
On Thu, Jan 16, 2020 at 10:53 PM Jerry James
> On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia <nkadel(a)gmail.com> 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
> 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.
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
cannot reasonably be discarded and rebuilt from scratch for new
versions of that software, without Berkeley DB entirely, as part of a
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.