Dear Maintainer, Following a recent discussion on debian-devel@[1], there is a plan to dismantle the default-mysql-* virtual package construct provided by the mysql-defaults source package. With the recent releases of MySQL 9.7 and MariaDB 12.3, there is now enough divergence between the two codebases to warrant dismantling this metapackage in the Forky (Debian 14) cycle. This is filed with severity 'normal' as this change is not urgent. We are asking maintainers to drop any dependencies on these virtual packages: * default-libmysqlclient-dev * default-mysql-client * default-mysql-client-core * default-mysql-server * default-mysql-server-core However, how this is handled in is in your discretion based on the details of how the package is maintained and tested in Debian. There are mainly three options: - Direct switch: The most straightforward approach is to switch defaut-mysql-* directly to the MariaDB equivalent (libmariadb-dev, libmariadb-dev-compat, mariadb-client, mariadb-server, etc). For example 'Recommends: mariadb-server'. - Dual compatibility: If the package actively supports both engines and you wish to keep an alternative runtime path open for users drawing from third-party repositories, you can declare an OR dependency. For example 'Depends: mariadb-client | mysql-client'. - Specific constraint: If your package does not work with MariaDB, feel free to tailor the package relationships to match that constraint. This is however very unlikely as all Debian releases in past decade have only shipped with MariaDB, and the open source ecosystem has largely shifted to lean towards MariaDB. This change is targeted specifically for the Forky cycle and does not affect any existing stable releases. Thank you for your time and your work maintaining rsyslog in Debian! [1] https://lists.debian.org/debian-devel/2026/05/msg00161.html
Am 27.05.26 um 04:22 schrieb Otto Kekäläinen: As long as https://lists.debian.org/debian-devel/2026/05/msg00256.html is not sufficiently answered, I will wait with making any changes. Regards, Michael
Am 27.05.26 um 04:22 schrieb Otto Kekäläinen: btw, do you want me to rename the package to rsyslog-mariadb ? That would be the logical conclusion from your bug report but I want to be sure.
Am 27.05.26 um 18:30 schrieb Michael Biebl: And if so, is there an equivalent to dbconfig-mysql ? It seems you want to eradicate mysql, but I don't see how this would work.
I think it would be a disservice to everyone if we introduce naming that upstream doesnt use. F.e. if upstream calls the plugin "mysql", then in Debian it should continue to be called "mysql"... Otherwise this will just be super confusing for everybody. Chris
Hi, I need the help of maintainers to research this for each individual packages. Some upstreams like WordPress, Nextcloud, Drupal were clearly state in their documentation that they recommend MariaDB. This implies they are less likely to rewrite stuff to adapt to new MySQL versions that drop functionality. This already happened in WordPress, which was (and perhaps still is) incompatible with MySQL 8.4 because it dropped the SQL_CALC_FOUND_ROWS feature. Quickly skimming rsyslog documentation and source I see that it mentions "MariaDB/MySQL" everywhere. I am not sure if MariaDB being mentioned first has significance in this context. I tried to read what the rsyslog CI does, but the mix of GitHub actions and custom Buildbot made it difficult to determine which MySQL and MariaDB versions they are testing. Note that I filed this issue with severity "normal", so immediate changes aren't required. You can wait and see what your upstream does and make the change later in the Forky development cycle.
Hi all, rsyslog upstream here. Let me clarify: we are very much in favor of MariaDB, BUT: ommysql is a plugin name that you load in config. if it is renamed, all existing configs will break. Not an option. That said, we think about building an internal alias table for cases like this, where you could load it as either ommysl or ommariadb. This, however, is against rsyslog policies, where we avoid fixed names and just infer the naming from the loaded module. But it may by acceptable for exceptional cases like this.. Symlinking might be another approach, but IMHO that would be too distro-specific. Functionality wise, rsyslog does not care much about the backend, because we do basically "insert" statements by default. Plus transactions. Nothing fancy, so any engine will do. CI has relatively old versions for that reason (so much todo, we do not update without need). Users may do more clever things, but basically still down to a single statement / stored procedure. Those who do these things definitely know which db engine they are using and why. I hope that helps with finding the best way for Debian. I would also be happy for some thoughts on aliasing the module names rsyslog internally. Thanks, Rainer El jue, 28 may 2026 a las 4:53, Otto Kekäläinen (<otto@debian.org>) escribió:
Am 27.05.26 um 18:36 schrieb Michael Biebl: Apologies, eradicate was a bad choice of words. Michael
Hi Michael, You currently have in https://salsa.debian.org/debian/rsyslog/-/blob/debian/latest/debian/control: Package: rsyslog-mysql ... Recommends: default-mysql-client | virtual-mysql-client Suggests: default-mysql-server | virtual-mysql-server I recommend changing this to: Recommends: mariadb-client | mysql-client | virtual-mysql-client Suggests: mariadb-server | mysql-server | virtual-mysql-server This is sufficient for the topic of this bug report.
Am 28.05.26 um 16:26 schrieb Otto Kekäläinen: Why the alternative dependency on mysql-client? What exactly would that achieve and why not "mariadb-client | virtual-mysql-client" Btw, given that rsyslog has a Build-Depends on default-libmysqlclient-dev, I assume the plan is to retire this package as well? If any changes are done in this regard, I think they should be done at the same time.