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 (<[email protected]>) escribió: > > Hi, > > > As long as https://lists.debian.org/debian-devel/2026/05/msg00256.html > > is not sufficiently answered, I will wait with making any changes. > > 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.
