kde/tracker

Fork 0

comps: drop akonadi-server-mysql from defaults #730

New issue

Open

opened 2026-09-26 12:14:58 +00:00 by geldot · 3 comments

geldot commented

2026-09-26 12:14:58 +00:00

Akonadi has defaulted to SQLite since KDE Gear 26.04. The KDE desktop comps group should no longer explicitly select the MySQL backend.

The proposed changes remove around 90 packages from the transitive dependency set which reduces installed footprint by some 184 MiB, so a KDE Plasma desktop setup no longer pulls in a full database server, corresponding dba admin tooling and the dozens of perl modules they depend on.

comps PR, up for SIG review:

releng/fedora-comps#1334

And here's the corresponding packaging change:

https://bugzilla.redhat.com/show_bug.cgi?id=2541777

Akonadi has defaulted to SQLite since KDE Gear 26.04. The KDE desktop comps group should no longer explicitly select the MySQL backend. The proposed changes remove around 90 packages from the transitive dependency set which reduces installed footprint by some 184 MiB, so a KDE Plasma desktop setup no longer pulls in a full database server, corresponding dba admin tooling and the dozens of perl modules they depend on. comps PR, up for SIG review: https://forge.fedoraproject.org/releng/fedora-comps/pulls/1334 And here's the corresponding packaging change: https://bugzilla.redhat.com/show_bug.cgi?id=2541777

geldot referenced this issue from releng/fedora-comps

2026-09-26 12:15:23 +00:00

WIP: kde: drop akonadi-server-mysql from defaults #1334

tdawson commented

2026-09-28 19:06:31 +00:00

Member

We discussed this a bit in the KDE SIG meeting.
Looking at the akonadi-server package, it currently is set to use mysql, so that would need to be changed. Not much of a problem.

The big problem is for people who already have been using akonadi-server with mysql.

Does akonadi-server bring over the mysql stuff?
Is there a script, or something that will bring over your stuff if akonadi-server?

In short, we need some type of upgrade path.
Nobody on our call knew enough about akonadi to know how easy or hard doing a switch of backends would be.

We discussed this a bit in the KDE SIG meeting. Looking at the akonadi-server package, it currently is set to use mysql, so that would need to be changed. Not much of a problem. The big problem is for people who already have been using akonadi-server with mysql. - Does akonadi-server bring over the mysql stuff? - Is there a script, or something that will bring over your stuff if akonadi-server? In short, we need some type of upgrade path. Nobody on our call knew enough about akonadi to know how easy or hard doing a switch of backends would be.

geldot commented

2026-09-28 22:05:35 +00:00

Author

@tdawson wrote in #730 (comment):

Does akonadi-server bring over the mysql stuff?

Is there a script, or something that will bring over your stuff if akonadi-server?

In short, we need some type of upgrade path. Nobody on our call knew enough about akonadi to know how easy or hard doing a switch of backends would be.

There is akonadi-db-migrator. It ships in the akonadi-server package.

However, I couldn't get a sense of how stable / up-to-date it is from public reports. So I just dedicated a couple of hours to science to get a definitive answer.

geldot         7747  1.8  0.1 8591629112 91180 ?    Sl   21:07   0:00 /usr/bin/mysqld --defaults-file=/home/geldot/.local/share/akonadi/mysql.conf --datadir=/home/geldot/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid

I created some half a dozen sets of contacts, calendar events, and mail items, populating fresh instances of the above locally activated user scoped mysqld (actually mariadb) instance.

After each test set, I ran akonadi-db-migrator --newengine sqlite

$ akonadi-db-migrator --newengine sqlite
[snipped]
Optimizing table TagTypeTable...
Migrating table TagTable (11/17)...
Optimizing table TagTable...
Migrating table TagAttributeTable (12/17)...
Optimizing table TagAttributeTable...
Migrating table TagRemoteIdResourceRelationTable (13/17)...
Optimizing table TagRemoteIdResourceRelationTable...
Migrating table PimItemFlagRelation (14/17)...
Optimizing table PimItemFlagRelation...
Migrating table PimItemTagRelation (15/17)...
Optimizing table PimItemTagRelation...
Migrating table CollectionMimeTypeRelation (16/17)...
20%...
50%...
70%...
100%...
Optimizing table CollectionMimeTypeRelation...
Migrating table CollectionPimItemRelation (17/17)...
Optimizing table CollectionPimItemRelation...
Backing up original database...
Migration completed successfully.

The migrations have worked well each time. Once a migration is completed, it stores a backup of the original files and doesn't start up the mysql process after that point.

(I don't use KDE PIM but it seems to benefit from having full access to the object model as a compiled executable to achieve faithful migration, rather than being a migration script.)

However, there is no UX that I can find. And from my testing it seems to require the mysql engine to be installed.

The one thing I haven't tried yet is launching a session where the user still has unmigrated mysql data files but where the akonadi-server-mysql package has been removed.

@tdawson wrote in https://forge.fedoraproject.org/kde/tracker/issues/730#issuecomment-1360860: > * Does akonadi-server bring over the mysql stuff? > * Is there a script, or something that will bring over your stuff if akonadi-server? > > In short, we need some type of upgrade path. Nobody on our call knew enough about akonadi to know how easy or hard doing a switch of backends would be. There is [akonadi-db-migrator](https://userbase.kde.org/Akonadi/en#How_do_I_switch_from_MySQL/PostgreSQL_to_SQLite?). It ships in the [akonadi-server](https://packages.fedoraproject.org/pkgs/akonadi-server/akonadi-server/fedora-rawhide.html#files) package. However, I couldn't get a sense of how stable / up-to-date it is from public reports. So I just dedicated a couple of hours to science to get a definitive answer. ```sh geldot 7747 1.8 0.1 8591629112 91180 ? Sl 21:07 0:00 /usr/bin/mysqld --defaults-file=/home/geldot/.local/share/akonadi/mysql.conf --datadir=/home/geldot/.local/share/akonadi/db_data/ --socket=/run/user/1000/akonadi/mysql.socket --pid-file=/run/user/1000/akonadi/mysql.pid ``` I created some half a dozen sets of contacts, calendar events, and mail items, populating fresh instances of the above locally activated user scoped mysqld (actually mariadb) instance. After each test set, I ran `akonadi-db-migrator --newengine sqlite` ``` $ akonadi-db-migrator --newengine sqlite [snipped] Optimizing table TagTypeTable... Migrating table TagTable (11/17)... Optimizing table TagTable... Migrating table TagAttributeTable (12/17)... Optimizing table TagAttributeTable... Migrating table TagRemoteIdResourceRelationTable (13/17)... Optimizing table TagRemoteIdResourceRelationTable... Migrating table PimItemFlagRelation (14/17)... Optimizing table PimItemFlagRelation... Migrating table PimItemTagRelation (15/17)... Optimizing table PimItemTagRelation... Migrating table CollectionMimeTypeRelation (16/17)... 20%... 50%... 70%... 100%... Optimizing table CollectionMimeTypeRelation... Migrating table CollectionPimItemRelation (17/17)... Optimizing table CollectionPimItemRelation... Backing up original database... Migration completed successfully. ``` The migrations have worked well each time. Once a migration is completed, it stores a backup of the original files and doesn't start up the mysql process after that point. (I don't use KDE PIM but it seems to benefit from having full access to the object model as a compiled executable to achieve faithful migration, rather than being a migration script.) However, there is no UX that I can find. And from my testing it seems to require the mysql engine to be installed. The one thing I haven't tried yet is launching a session where the user still has unmigrated mysql data files but where the akonadi-server-mysql package has been removed.

geldot commented

2026-10-01 20:16:32 +00:00

Author

OK, we have a clear first step: https://src.fedoraproject.org/rpms/akonadi-server/pull-request/7

This changes the alternatives priorities so new users get sqlite. No deps change or migrator yet.

I've run-tested and confirmed that users who haven't yet migrated will still get their usual mysql instance spawned up, so it's conservatively safe and should be good for F44, F45 too.

@tdawson PTAL so we get that in the bag. Each new user who starts out with sqlite is one less user whose migration we'll have to support.

Meanwhile, I'll have an update soon on potential strategies to migrate or alert users. Testing confirms that simply dropping the dependency results in a sub-optimal outcome for existing users.

OK, we have a clear first step: https://src.fedoraproject.org/rpms/akonadi-server/pull-request/7 This changes the alternatives priorities so new users get sqlite. No deps change or migrator yet. I've run-tested and confirmed that users who haven't yet migrated will still get their usual mysql instance spawned up, so it's conservatively safe and should be good for F44, F45 too. @tdawson PTAL so we get that in the bag. Each new user who starts out with sqlite is one less user whose migration we'll have to support. Meanwhile, I'll have an update soon on potential strategies to migrate or alert users. Testing confirms that simply dropping the dependency results in a sub-optimal outcome for existing users.

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

kde/tracker#730

No description provided.

Rows
Columns