MDEV-15526: remove mysql/mysqld service aliases for systemd

[grooverdan]

per #1172 (comment) the plan was to remove the aliases in 10.5 as they violate the debian packaging rules.

This didn't seem to happen.

Downstream want to keep the links https://salsa.debian.org/mariadb-team/mariadb-10.4/-/merge_requests/2.

No-one really needs them. They were really added without being aware of the total broken state of aliases.

Merge this and I'll write something in the kb release notes to be sure that the few that are surprised can get back to their happy state quickly.

[ottok]

Yes, we need the links and we need to support both systemd and traditional init. Traditional init is still used by Docker containers, Windows subsystem for Linux, many non-systemd Linux systems etc.

The PR #1172 is correct code wise. Unfortunately it did not do a great job in explaining why those changes are needed and now everybody are confused.

I plan to finalize #1172 with a couple of debian/rules tweaks and also proper test cases to validate that all use cases will work with the final fix and no drawbacks to anybody.

[grooverdan]

Confused, and annoyed. Given the MariaDB direction to use its own naming this should be easy.

Docker just uses mysqld and not the init script. To use an initscript in a container isn't useful. Those that use it deserve any pain that comes to them.

Anything that uses them can be changed. After all a major upgrade requires a little testing is required.

[cvicentiu]

@grooverdan Notice that until very recently MariaDB was considered as a drop-in replacement for MySQL. I am not here to debate the truthfulness of that fact, but we are taking this naming change one step at a time. The key is to not surprise users.

If we were to remove aliases as well as symlinks, we would be in a position with a whole bunch of commands like mysqld, mysql, mysqldump, etc. that reference mysql, but absolutely no reference to mysql (or mysqld) within systemd.

In this case, I don't think this is the right approach for our user base. We took a step now to rename things. 10.4 has symlinks mariadb branded and mysql branded binaries. 10.5 has symlinks mysql branded and mariadb branded binaries. To me it seems like the earliest we could make such a change is in 10.6.

In either case, the final step of completely removing mysql will always be the hardest and should be done in one go, with proper testing, community feedback and lots of opportunities for debate. In this sense, even 10.6 looks unlikely.

I have looked into #1172 and tested how symlinks work. I am not 100% sure if either this one or #1494 is the right approach, so I will defer from closing any until we have discussed the user implications with @ottok , @vuvova, @ericherman, @montywi .

To those pinged above, please read #1172 and #1494. My vote is for #1172 as it provides the least surprises for our users.

[grooverdan]

For 10.4, sure merge #1172 if its been tested, I'm not sure why it hasn't already.
For 10.5, I was following the advice previously advised of and wrote this specificity for 10.5 given not much else is being looked at, especially on the packaging with the exception of a bulk of last second debian changes.

Symlinks status as aliases seems to have some official status finally, so ok, sure use them. I even tested the dependency nature of services and it seems fine.

[cvicentiu]

It looks like we are getting closer to a consensus.

As these changes have been rather contested, before I fire I'd like for us to get a chance to discuss this via voice. I think that a quick 15-30 minutes call can make sure we are all on the same page.

@ottok @grooverdan @fauust and anyone else interested, would you be available to have a quick chat in the next few days?

Attached a doodle to vote on. We'll use the Foundation zoom channel, which I'll email once we agree on a time.

https://doodle.com/poll/tqunfssmcx5wcib7

(as a side thought, if we are all getting on a call, perhaps we can dig into other packaging pain points too with those who can stay for longer afterwards).

[ottok]

I have a work-in-progress on this topic on ottok:ok-10.5-init-support. I have also developer a script to test this etc. I am mentally not ready to discuss the details of this until I have all the details sorted out in my head and proven with test cases. Also I don't think any of us are ready to dive into this before #1478 is finalized. And once that is done, I need to quickly finalize #1496 and only then I think we are ready to properly discuss and re-visit MDEV-15526 and the many PRs that relate to it.

[cvicentiu]

Closing this one and we will move the discussion to #1172.