On Fri, 2021-04-16 at 16:31 +0000, David Cantrell wrote: > > https://fedoraproject.org/wiki/Change/CyrusSaslBerkeleyDBtoGdbm > > > > == Summary == > > cyrus-sasl package was built with libdb requirement, now it is replaced by gdbm. > > > > == Owner == > > * Name: [[User:Dbelyavs| Dmitry Belyavskiy]] > > * Email: dbelyavs(a)redhat.com > > > > > > > > == Detailed Description == > > This change switches the default backend Key-Value DB used by sasldb > > plugin from BerkeleyDB to GDBM and provides a migration tool for > > automatic conversion from old to new format. > > > > > > == Benefit to Fedora == > > According to more restrictive libdb licence policy exists effort to > > remove libdb's dependencies. > > cyrus-sasl package can now be built without libdb requirement. > > > > > > == Scope == > > * Proposal owners: > > * Other developers: The owners of the packages depending on cyrus-sasl > > sasldb plugin should provide the documentation about the migration > > procedure. > > > > * Release engineering: [https://pagure.io/releng/issue/10084] > > * Policies and guidelines: not needed for this Change > > * Trademark approval: N/A (not needed for this Change) > > * Alignment with Objectives: > > > > > > == Upgrade/compatibility impact == > > The migration script should be used to upgrade the particular > > databases used by specific applications via sasldb plugin > > > > > > == How To Test == > > * Install the new version of the cyrus-sasl. > > * Use the migration tool bdb2current provided by the package to > > migrate your sasldb file > > * update the configuration file to point on the new sasldb file > > * restart the application if necessary > > * Check that auth is still working > > > > > > == User Experience == > > not provided > > > > == Dependencies == > > A lot of application use cyrus-sasl sasldb plugins. Their maintainers > > were notified via email and some of them have responded. > > > > > > == Contingency Plan == > > * Contingency mechanism: Revert the shipped configuration > > * Contingency deadline: Beta freeze > > * Blocks release? Yes > > > > > > == Documentation == > > Here is the notification sent to known developers of the depending packages: > > > > New version of the cyrus-sasl is planned to use the gdbm database for > > the sasldb plugins. > > > > I've implemented the patch > > (https://src.fedoraproject.org/rpms/cyrus-sasl/pull-request/3#request_diff) > > changing the default DB and implementing the migration tool to make > > the switching from BerkeleyDB to GDBM seamless. > > > > I kindly ask you to check the information in the following spreadsheet: > > https://docs.google.com/spreadsheets/d/1z5eTSm3rtlKtEKPCxhI_wE861Xzg8kbvI...: > > > > whether your package is affected by the proposed change > > whether the migration tool is suitable for your purposes > > > > and let me know or mark the results in the table > > > > > > == Release Notes == > > a new version of the cyrus-sasl package is landing in rawhide. > > > > This version changes the database used to store saslauthdb data. This > > is part of the move to deprecate use of Berkley DB. The new package > > will use GDBM instead. > > > > We provided a tool to perform migrations for database should that be > > needed by a package: > > > > The syntax of the migration tool is > > bdb2current <sasldb path> <new_path> > > > > Please check whether your packages use the sasldb plugin and provide a > > relevant migration guideline. > > A couple of questions: > > 1) The contingency plan does not make it clear how users revert if > the BDB version of Cyrus SASL has to return. Does the migration tool > leave a copy of the previous db file or files in place that can be > used by the BDB version of Cyrus SASL? Should the new file be > migrated back in case of changes post-migration? The migration tool creates a new file, so the previous DB should remain available. We do not really have a way to convert back though, modifying the migrations script to go ther way around should be possible, but unclear if that is really required as you have a backup of th user's db at time of migration. > 2) I'm curious why GDBM was chosen instead of something like sqlite. > > Thanks, > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
