On Wed, Feb 1, 2023 at 1:57 PM Milan Crha <mcrha(a)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...
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 =)