akonadi server support any backend from package dependency point of view.
However trying to start it via

akonadictl start you get:

org.kde.pim.akonadictl: Starting Akonadi Server...
org.kde.pim.akonadictl:    done.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
valette@tri-yann4:~$ org.kde.pim.akonadiserver: Starting up the Akonadi Server...
org.kde.pim.akonadiserver: Did not find MySQL server default configuration (mysql-global.conf)
org.kde.pim.akonadiserver: Failed to remove runtime connection config file
org.kde.pim.akonadiserver: Shutting down AkonadiServer...
org.kde.pim.akonadicontrol: Application '/usr/bin/akonadiserver' exited normally...

However the file

/etc/xdg/akonadi/mysql-global.conf  comes only with package
akonadi-backend-mysql and manually adding an empty file the error disappers but then it
barks again later with mysql not running.

severity 969171 normal
thanks

Dear Eric.

Akonadi will use whatever database is set in the configuration file, by
default on first startup MySQL if the MySQL backend has been installed at
first startup. So if you use it with an existing home directory that has
MySQL specified as database backend it needs the MySQL database backend
of Akonadi to operate with the existing configuration. See the file:
'~/.config/akonadi/akonadiserverrc'. This can happen as easily as
starting once with the MySQL backend installed, as Plasma starts Akonadi
automatically in its default configuration. Then you have an empty
MariaDB based Akonadi. If you then switch to PostgreSQL this error
occurs.

Please ask on debian-kde and/or upstream kdepim-users mailing list for
support. The Debian bug tracker is not for user support questions. Also
review previous threads on this topic there. Note that on switching the
database Akonadi will start anew and some information only stored in the
database will be lost.

I think it is not a bug of the package. But it is definitely not severity
grave as Akonadi is perfectly usable here in exact the same version
(usable to the extent Akonadi works reliable, but that is an upstream
issue). So downgrading severity to normal.

I have seen repeatedly seen that you set too high bug severity. If the
package does not work for me does not mean that its automatically grave
severity. Especially when it is, as I assume, a configuration error. So
please refrain from setting grave when it isn't. It just causes
additional work for the already overloaded Debian Qt/KDE team. If you
are unsure please ask first in debian-kde mailing list. That is part of
what it is there for.

Best,

When only akonadi-backend-sqlite is installed as you can see in
installed packages I find normal that the default config file is changed
to use sqlite by default as I would expect that removing
akonadi-backend-mysql would remove the mysql backend if it was used with
a warning.

But apparently, you are more interested in having the package without
bug than working to simplify your user's life.

Hey,

Debian can't easily distinguish, if you only installed one backend or differnt
ones. Well we could add logic to detect this, but that would be very error
prune.

So the proper solution needs to be done upstream aka in Akonadi directly.
Akonadi has no support to check what different backends are available but
simply try to start mysql. And if you tried it once, than Akonadi has created
a user config that selects the mysql database and it is outside our control to
switch the backend. Because Debian packages are not allowed to touch any stuff
in $HOME.

Never the less in future for trixie the situation needs to be improved, as
Akonadi switched its default backend over to SQLite (see #1034561). Detecting
available backends is becoming a bigger issue.

Any help from your side to fix the problem is highly welcome: merge request,
upstream bug report, patch etc. Unfortunately the Debian maintainers team is a
lot of work and not enough resources, to do all work.

Regards,

hefee

#1034561: https://bugs.debian.org/1034561