It has to be said that the patches should be inspected before applying. It can happen that not all of them will be necessary or you may find some of them inconvenient. So please don't forget to review them. Thank you.

https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-5.1.50-strncat-overflow.patch
This patch suggests to subtract strlen(buff) twice. Looks like incorrect port from MySQL. There's no possible buffer overrun in MariaDB anyway.

serg, please review ported patch https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-5.5.32-upgrade-exit-status.patch

Patch is at commits@.

I don't have an opinion about this patch. Up to you.

I believe it is reasonable request: scripts somehow need to distinguish between real failure and "up to date". What I'm not sure about is if there is a need to distinguish between "up to date" and "job done", but we can fix that easily if needed anyway.

kstreitova, miska, a question re https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-5.5.28-install_db-quiet.patch: there is mysql_install_db --rpm, which suppresses this output. Why didn't it work for you?

I'm afraid that --rpm option would change the mysql_install_db script behaviour more than we want. If we use --rpm option it will also disable echoes about how to start and test MariaDB daemon. And we just want to adjust these echoes not disable them.

Regarding
https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-5.5.32-upgrade-exit-status.patch
Applied, rev. bfe2689cf642aac122c8cf8493863dff38f69558

It seems that there is no commit for 10.1.x branch. Is it ok? Thank you.

kstreitova, yes, it's ok. We'll merge it 5.5 -> 10.0 -> 10.1 before next release.

• https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-5.5.33-deharcode-libdir.patch
  INSTALL_LIBDIR_RPM and INSTALL_PLUGINDIR_RPM are internal variables and not supposed to be set by users. Please adjust your scripts to use INSTALL_LIBDIR and INSTALL_PLUGINDIR instead.

serg, please suggest what should we do about https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-10.0.15-fortify-and-O.patch

that's tokudb, should probably be reported to percona first.
I'm fine with not forcing -O and _FORTIFY_SOURCE=2 in tokudb, as long as our global -O and _FORTIFY_SOURCE=2 (in 10.1) apply.

serg, please have a quick look at 5.5 patches, specifically there seem to be some very suse specific ones. Do we want to take them?

1. https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mysql-community-server-5.1.45-multi-configuration.patch

I don't mind, but not in /etc/my.cnf — in /etc/my.cnf.d/mysqld_multi.cnf

2. https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mysql-community-server-5.1.46-logrotate.patch

error message is kind of ok. The path change, of course, we cannot take. We can make it configurable and suse will need to build with -DLOG_PATH=/var/log/mysql. Let's do it if they'll prefer a compilation option over a patch.

3. https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-5.5.28-install_db-quiet.patch

again, partially. I agree that mysql_install_db should not say "To start mysqld at boot time you have to copy support-files/mysql.server to the right place for your system" for any rpm or deb packages. But the second chunk is suse specific, we cannot take it.

4. https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-5.5.25-mysqld_multi-features.patch

these features are ok. But I think that --datadir is a confusing name for "create data directory and install privilege tables" functionality. And I wouldn't use killproc — kill is as good and it is installed everywhere.

5. https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-5.2.3-cnf.patch

I woldn't bother. These files are obsolete anyway

6. https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mysql-community-server-5.5.6-safe-process-in-bin.patch

I don't understand why

7. https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mariadb-5.5.28-group.patch

I'm fine with adding support for a group, but this patch doesn't seem to have a server part. It adds --group to the command line and the server doesn't recognize this option. And, btw, I would rather not add a new option, but extend --user to support the conventional user:group syntax.

8. https://github.com/openSUSE/mysql-packaging/blob/master/patches/mysql-patches/mysql-5.5.31-upgrade-datadir.patch

this seems ok. The last hunk is fragile. They do upgrade_already_done() because it needs the datadir and they want to have it in the cache. It's an obscure side effect, I'd rather keep that if() as is and add an explicit

    get_upgrade_info_file_name(something); // cache the datadir

or, even better, extracted that in a separate function, like, get_datadir().

Summary:

• We can take first and eighth (last) patches with slight modifications.
• Seventh — would be ok, if they'd explained how it works without server side changes.
• Second, third, fourth — we can take them in some form, so that suse won't need patches. But they'll need to change build or install scripts. And as they need some changes anyway, may be they'll prefer to stick with patches.

kstreitova, I don't see MariaDB/MySQL 5.5 at https://github.com/openSUSE/mysql-packaging anymore. Does it still make sense to apply patches to 5.5?

Sergey, from our point of view I would say it isn't worth it. We don't have MariaDB 5.5 in any supported product anymore.

kstreitova, I updated task accordingly, thanks! Please also see notes re mariadb-10.0.5-deharcode-libdir.patch and mariadb-10.0.10-string-overflow.patch in task description. It would be nice to have answers for Serg's questions too.

mariadb-10.2.3-mysql_install_db-mariadb_dirs.patch - hopefully fixed with 52516706c86f9f66c76836eabde7e2477694bac3
mariadb-10.2.3-systemd-cmake.patch - looks like -DWITH_SYSTEMD=no would follow the true paths.

Requested feedback in opensuse bug 1080891, seems a lot has been removed since this was opened.

I had relook at other distro patches/packaging to what could be done to converge and made comments on their bug. https://build.opensuse.org/package/revisions/server:database/mariadb .

anything still needs to be done here?

Most probably yes.

Regarding mysql-community-server-5.1.46-logrotate.patch: Sergei mentioned that the path can be configurable and then we would need to build it with DLOG_PATH=/var/log/mysql. I think that this compilation option is definitely better than a patch for us. So we are ok with it.

Regarding mariadb-5.5.28-group.patch: You are probably right regarding this patch. It was added many years ago by the previous maintainer and I'm not sure what was the initial idea behind this. But it really looks like a half solution of the problem. Using a group option within our systemd-helper script was removed a few years ago as it caused troubles because MariaDB resolved "group" option as a "group_concat_max_len" option (see https://github.com/openSUSE/mysql-packaging/issues/15). I think that we can remove this patch because we no longer use group option anyway. However, I guess that adding proper and full support for a group option would be a really nice feature.

OpenSUSE is now shipping 10.3. Would it be worth revisiting this? It's down to 6 patches in obs https://build.opensuse.org/package/show/server:database/mariadb

All relevant Suse patches has been added.
A few to 10.2, the others to 10.3.