Description of problem: BerkeleyDB 6.x and later versions have a more restrictive license than the previous versions (AGPLv3 vs. LGPLv2), and due to that many projects cannot use it, it's time to replace this database by others (GDBM, SQLite, ...). Actual results: Some packages depend on libdb Expected results: none libdb dependency
This license change is why the version in Fedora is still 5.x Some sort of effort to replace it would be welcome I am sure, but it's likely to be a lot of work for whoever takes it on. Moving to libdb for comment.
Filip is the one person driving this from the libdb side. Not sure what purpose this bug report was supposed to serve, but we do have a (ancient) tracker bug for the transition you might want to reuse: https://bugzilla.redhat.com/show_bug.cgi?id=1361971
Filip, is there a special reason that RPM itself isn't listed here? RPM uses libdb, even it usually bundles it internally nowadays (which is also not either), but the better approach would be IMHO to make RPM switching to LMDB or similar - no?
s/which is also not either/which is also not great/ # Sorry And please note that bug #1086784 covering RPM was closed by it's maintainer.
You are right RPM and others components contain libdb dependency, I am trying to contact all component's maintainers gradually and solve this problem, so RPM would be add in the near future.
Do you think it would be possible to provide a ldb-compat package stuck at this older version for those packages that have a data format dependency? I think I may be able to change my package (cyrus-sasl) to use a different db by default, but I do not want to break people that already have a sasl db somewhere in use (I can't do package install time migrations because the db can be anywhere).
I understand Your problem with databases locations, but the actual state is very similar to compact package, we are maintaining version 5.x.x and actual upstream version is 18.x.x, it could lead in future to unexpected running problems or problems with compiling. Complete removal will take probably more than one Fedora release, but we would like to find a solution to your issue. Do you have some opinion except compat package?