MDEV-40964: Update default datadir for debian to be /var/lib/mariadb

[lvoytek]

Match the existing datadir setting for Debian and Ubuntu, which was changed from /var/lib/mysql to /var/lib/mariadb in 1:11.8.6-5.

Existing Debian patch: https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/patches/set-default-datadir-to-var-lib-mariadb.patch

[CLAassistant]

All committers have signed the CLA.

[gemini-code-assist]

Code Review

This pull request updates the default data directory for Debian-based installations in cmake/install_layout.cmake by changing INSTALL_MYSQLDATADIR_DEB from /var/lib/mysql to /var/lib/mariadb. No review comments were provided for this change, and I have no feedback to provide.

[vuvova]

Questions:

• this is the main branch, so 13.0. A bit too late for Ubuntu?
• what about upgrades 12.3→13.0 ? May be not a problem for Ubuntu, but the change affects our (vendor) packages too.
• How does Ubuntu build MariaDB packages? You likely don't use our autobake.sh script, do you? In that case
  • we can set INSTALL_MYSQLDATADIR=/var/lib/mysql from our autobake.sh and keep the old path in vendor builds and the new path in Ubuntu builds
  • or Ubuntu can set INSTALL_MYSQLDATADIR=/var/lib/mariadb and get a new path without affecting vendor builds. I think the first approach might be easier.
  • or we can change all, Ubuntu and vendor, builds, and then pre/post-inst scriptlets need to handle the upgrade and move the data to the new location

@ottok, what do you think?

[grooverdan]

Thanks @lvoytek

Questions:

* this is the `main` branch, so 13.0. A bit too late for Ubuntu?

Ubuntu 26.04 already carrying the patch for 11.8_+
bugs.launchpad.net/ubuntu/+source/mariadb/+bug/2148632

* what about upgrades 12.3→13.0 ? May be not a problem for Ubuntu, but the change affects our (vendor) packages too.

I opened https://jira.mariadb.org/browse/MDEV-39461

But yes, we'll need the scripts too.

* How does Ubuntu build MariaDB packages? You likely don't use our `autobake.sh` script, do you? In that case

Like Debian - straight from debian/rules

  * we can set `INSTALL_MYSQLDATADIR=/var/lib/mysql` from our `autobake.sh` and keep the old path in vendor builds and the new path in Ubuntu builds
  * or Ubuntu can set `INSTALL_MYSQLDATADIR=/var/lib/mariadb` and get a new path without affecting vendor builds. I think the first approach might be easier.
  * or we can change all, Ubuntu and vendor, builds, and then pre/post-inst scriptlets need to handle the upgrade and move the data to the new location

I do like the last plan.

Question is, do we stop on Deb changes or include RPM too?

@ottok, what do you think?

Its already in Debian sid.

https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/155

I was hoping to see more of the script changes from that here.

Having a modified subset in 11.8 to handle Ubuntu upgrade to our vendor ones would be good too to solve MDEV-39461. Probably like a earlier version in salsa merge request 155 that dropped the config file in the post install without changing the default.

[gkodinov]

This is a preliminary review. Can you please describe the problem you're solving? I.e. what happens now and how is that wrong. And how your solution goes about solving the problem, i.e. how is the current behavior modified.
Ideally this should happen in an MDEV prior to submitting a PR for it, but I can also file one for you if you put your rationale into the PR itself.

[ottok]

If I am not mistaken, the submitter of this patch (Canonical employee) had some discussions with Sergei about switching the datadir to /var/lib/mariadb in MariaDB. This submission does that, and targets main to be in the next upstream MariaDB release.

This was already included in Debian and Ubuntu 1:11.6.8. The commit https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/2bf6f4d3e1cb090ad5ba7f443ae02af5047c5391 in Debian is a bit more verbose than the commit message/description in this PR.

I approved this change in Debian with the assumption that upstream will eventually follow in some future version. This PR only updates the _DEB variable but you might as well also update the equivalent _RPM variable.

From my point of view this would be fine to merge as-is, and perhaps MariaDB devs can follow-up with whatever additional changes are needed to make /var/lib/mariadb the default datadir on all new (fresh) installations?

Upgrades of old installs will continue to use /var/lib/mysql, at least with how the package maintainer scripts are done in Debian/Ubuntu.

[vuvova]

I like this 99-legacy-datadir.cnf technique, if we adopt that we can change the default indeed.

@lvoytek, your commit in Debian changes a lot more than this PR, are the other changes needed? Why did you omit them here?

[lvoytek]

I'm happy to include the packaging delta here too, I'll update the pr with it soon!

[lvoytek]

Sorry for the delay, all relevant changes for the datadir update should now be here

[ottok]

I reviewed and approved the original changes in Debian/Ubuntu, and I support having these upstreamed to MariaDB 'main' to be in effect in the next upstream release.

Hopefully someone can holistically review the MariaDB packaging after this is merged and add RPM changes and whatever is needed so that upstream can announce /var/lib/mariadb as the new datadir location in the next new version release.

CI is failing on two jobs. They should be checked before merging this. Unfortunately latest commit on 'main' is also failing, so I guess contributors to MariaDB shouldn't expect their PRs to pass CI either, but still good to take a look if there is something relevant looking.

(Upstream is not using Salsa CI, so the Salsa CI update is moot and the rest of the Salsa CI won't be passing anyway, but having this commit won't make anything worse either.)

[lvoytek]

Hello! Just pinging to request a re-review with the additional packaging changes included. Thanks!

[gkodinov]

Hello! Just pinging to request a re-review with the additional packaging changes included. Thanks!

Sorry for the delay. You have an assigned reviewer on this one. Let's wait for Serg's review please.

[gkodinov]

Thank you for your contribution! This is a preliminary review.

I'd advise to merge the 9 commits from this PR into (hopefully) a single one (unless there's legitimate reason to keep them all, which I can't really think of by myself), and maybe even consider merging this with PR#5649 (as suggested).

[lvoytek]

Reduced everything to one commit, working on adding the changes from #5646 and #5649 here too

[gkodinov]

LGTM. Please keep working with Daniel on the final review.

[grooverdan]

Minor tweaks, otherwise ok. Feel free to disagree.

On RPM, we've got selinux as an external package to contend with - devexp-db/mysql-selinux#16.

On the logic to create the new /var/lib/mariadb in the preinst, as this is where the mysql user is created, it could create a mariadb user if the new path is taken, and use that user permissions on /var/lib/mariadb, drop user=mariadb into the config, and a systemd override of User=mariadb (adjust logrotate script - seems rather dated thinking about it). WDYT?

[lvoytek]

On the logic to create the new /var/lib/mariadb in the preinst, as this is where the mysql user is created, it could create a mariadb user if the new path is taken, and use that user permissions on /var/lib/mariadb, drop user=mariadb into the config, and a systemd override of User=mariadb (adjust logrotate script - seems rather dated thinking about it). WDYT?

I'm not against moving to a mariadb user for new installs, though there could be additional regressions here and we would have to make sure all other necessary folders belong to that user instead. @ottok do you think it would be reasonable to include that too

[lvoytek]

Updated with requested changes

[lvoytek]

Also added changes from #5646. I can squash the commits together if preferred

[lvoytek]

also rebased onto main

[ottok]

I'm not against moving to a mariadb user for new installs, though there could be additional regressions here and we would have to make sure all other necessary folders belong to that user instead.

I suggest to make the mysql to mariadb user change in a separate PR and perhaps also roll it out in a separate MariaDB release. It has higher regression risk that the file path changes, and it is better to implement and test separately, with option to revert it if necessary as a stand-alone thing.

[lvoytek]

I'm not against moving to a mariadb user for new installs, though there could be additional regressions here and we would have to make sure all other necessary folders belong to that user instead.

I suggest to make the mysql to mariadb user change in a separate PR and perhaps also roll it out in a separate MariaDB release. It has higher regression risk that the file path changes, and it is better to implement and test separately, with option to revert it if necessary as a stand-alone thing.

That sounds reasonable to me. I'll hold off on a PR for this for now but will provide one in the near future

[grooverdan]

I'm not against moving to a mariadb user for new installs, though there could be additional regressions here and we would have to make sure all other necessary folders belong to that user instead.

I suggest to make the mysql to mariadb user change in a separate PR and perhaps also roll it out in a separate MariaDB release.

It complicates the range of existing options that exist on a target system. Given Debian/Ubuntu has already done it maybe not that much.

With containers is seems there's some tough decisions to make, but I can handle those.

It has higher regression risk that the file path changes, and it is better to implement and test separately, with option to revert it if necessary as a stand-alone thing.

Note I was considering this as only a pre/postinst + a dropped configuration change for new installs, like /var/lib/mariadb, rather than a building configuration change.