Bug 1788186
Summary: | Removing libdb dependency from cyrus-sasl | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Filip Januš <fjanus> | |
Component: | cyrus-sasl | Assignee: | Dmitry Belyavskiy <dbelyavs> | |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 34 | CC: | anon.amish, crypto-team, jfch, jjelen, plautrba, redhat-bugzilla, ssorce, vanmeeuwen+fedora | |
Target Milestone: | --- | Keywords: | Triaged | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | cyrus-sasl-2.1.27-13.fc35 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1947971 (view as bug list) | Environment: | ||
Last Closed: | 2021-09-24 20:07:30 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1778802, 1947971 |
Description
Filip Januš
2020-01-06 16:14:14 UTC
Filip, is there a specific reason that you suggest gdbm rather lmdb? 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. This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32. Hi Filip, we have a proposed change to address this issue here: https://src.fedoraproject.org/rpms/cyrus-sasl/pull-request/3 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. 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. Dmitry did most of the work, so thanks go to him. We will plan for a F35 change once they open up. This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34. FEDORA-2021-ede3a14d4c has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ede3a14d4c 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. 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. |