On Wed, Feb 1, 2023 at 1:57 PM Milan Crha <mc...@redhat.com> wrote: > this is a query for an opinion and a best-practice experience for a > case when a package needs to change its internal database format > between versions, in an environment, which does not allow real > migration, aka the app cannot read both formats, it can use one or the > other. > > To be specific, the libdb package is going to be removed [1] sooner or > later, and one of the packages which still use it is Bogofilter [2]. > It's easy to just switch from libdb to SQLite in the .spec file, the > problem is that the years of user's training of the Bogofilter spam/ham > data would be lost by such change. The SQLite version cannot read the > libdb data and vice versa (obviously), thus there needs to be done some > manual migration by the users. The worst, the users may need to export > their wordlist data before the update/upgrade and import it back after > the update/upgrade. Also, when the bogofilter is run with the other > format of the wordlist database, it simply errors out and expects > manual intervention. It's also good, the old data is not completely > lost, after all, and the user is aware something changed. > > My idea was to help the users with the migration in a way that the > export of the libdb data could be done during the package update, in > the %pre stage. A very nasty way I came with is to traverse the /home/ > directories and if there exists the old database, then export it and > rename the old file, thus the new bogofilter can run, even with an > empty database. The thing is that the exported data is ready in such > case, no need to downgrade the package or install old Fedora or any > such thing just to recover the wordlist. It's the only advantage, while > there are many disadvantages: > - it's a nasty approach, the package should not touch users' home > - it works only if the user uses the default/expected setting; saving > the database into a different place voids this best-effort approach > - the exported file is owned by root/admin, which requires change of > the attributes thus the user can get rid of it > - the package cannot tell to the user what to do next, to restore > the exported data. > > I'm sure you might find more disadvantages, these are just the top > four. > > That being said, any such change surely deserves release notes, with > the commands what to do to export and then back import the wordlist. > There should be filled a corresponding Change too, I guess. > > Still, how does other packages migrate their data, or at least help the > users with the migration? Is there any way?
cyrus-sasl ships a migration tool for some transition period and suggests the user to manually invoke it: https://src.fedoraproject.org/rpms/cyrus-sasl/blob/rawhide/f/cyrus-sasl-2.1.27-Migration-from-BerkeleyDB.patch Personally, I believe that even automatically converting a database on access and leaving a backup is already borderline risky, as the administrator doesn't know that about the conversion and nobody looks at any logs if things keep working. Please let's not entertain the idea of actively crawling for databases =) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
