Bug 1788186 - Removing libdb dependency from cyrus-sasl
Summary: Removing libdb dependency from cyrus-sasl
Alias: None
Product: Fedora
Classification: Fedora
Component: cyrus-sasl
Version: 34
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Dmitry Belyavskiy
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 1778802 1947971
TreeView+ depends on / blocked
Reported: 2020-01-06 16:14 UTC by Filip Januš
Modified: 2021-09-24 20:07 UTC (History)
8 users (show)

Fixed In Version: cyrus-sasl-2.1.27-13.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1947971 (view as bug list)
Last Closed: 2021-09-24 20:07:30 UTC
Type: Bug

Attachments (Terms of Use)

Description Filip Januš 2020-01-06 16:14:14 UTC
According to more restrictive libdb licence policy exists effort to remove libdb's dependencies.
cyrus-sasl package is now built with libdb requirement, this package could be build without libdb. libdb could be replaced by gdbm.

Comment 1 Robert Scheck 2020-01-16 00:21:18 UTC
Filip, is there a specific reason that you suggest gdbm rather lmdb?

Comment 2 Filip Januš 2020-01-16 12:35:52 UTC
There are multiple choices(see: https://www.cyrusimap.org/sasl/sasl/installation.html#requirements). But from cyrus-sasl installation guide:
"If you are using SASLdb, you will need to pick your backend. libsasl2 can use gdbm, Berkeley db, or ndbm to implement its user/password lookup. Most systems come with ndbm." 
I am not sure, if cyrus-sasl with gdbm has same functionality as with lmdb. If so then lmdb could be used.

Comment 3 Ben Cotton 2020-02-11 17:35:04 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 4 Simo Sorce 2021-01-14 17:15:39 UTC
Hi Filip,
we have a proposed change to address this issue here:

I guess one question is how/when we should introduce this change in Fedora.

As you can see we have a migration script, but there is currently no automatic migration of the Database during an RPM upgrade. We can probably add a scriplet to catch a DB in the default path, but applications that may provide a bdb database in an alternative path would have to be changed to invoke the upgrade script I guess.

So guidance on how to proceed would be nice.

Comment 5 Filip Januš 2021-01-18 09:36:42 UTC
Hi, Simo
first of all thanks for your effort. It's great that you include also the support of conversion.

In the current state isn't possible to make one big Fedora change for all components, because some components need more time to implement other database support. Therefore I would recommend creating a change Into Fedora 35 for your component. 
If I can help in any way, I'll be happy to help.

Comment 6 Simo Sorce 2021-01-19 20:02:57 UTC
Dmitry did most of the work, so thanks go to him.

We will plan for a F35 change once they open up.

Comment 7 Ben Cotton 2021-02-09 16:23:50 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 8 Fedora Update System 2021-08-24 16:01:44 UTC
FEDORA-2021-ede3a14d4c has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ede3a14d4c

Comment 9 Fedora Update System 2021-08-25 18:36:26 UTC
FEDORA-2021-ede3a14d4c has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-ede3a14d4c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-ede3a14d4c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 10 Fedora Update System 2021-09-24 20:07:30 UTC
FEDORA-2021-ede3a14d4c has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.