On Thu, Jan 16, 2020 at 1:17 PM Jerry James <loganjerry(a)gmail.com> wrote:
On Thu, Jan 16, 2020 at 9:09 AM Filip Janus <fjanus(a)redhat.com> 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?