I installed dev-db/mariadb-10.4.6 and the files "/etc/conf.d/mysql" and "/etc/init.d/mysql" were not installed as they were in previous versions. If an upgrade is done, the those files from the old version will not be removed however the init file function get_config calls "my_print_defaults" which has moved to "/usr/libexec/mariadb/my_print_defaults" so the init file won't work until the path to "my_print_defaults" is changed.
Please provide 'emerge --info =dev-db/mariadb-10.4.6'. dev-db/mariadb-10.4.6 depends on dev-db/mysql-init-scripts if USE="server -prefix" is set, so it's likely the only bug here is that the initscript isn't set up to handle that my_print_defaults moved into /usr/libexec/mariadb.
(In reply to dwfreed from comment #1) > Please provide 'emerge --info =dev-db/mariadb-10.4.6'. > dev-db/mariadb-10.4.6 depends on dev-db/mysql-init-scripts if USE="server > -prefix" is set, so it's likely the only bug here is that the initscript > isn't set up to handle that my_print_defaults moved into > /usr/libexec/mariadb. Ah, I was not aware that the init scripts were provided by dev-db/mysql-init-scripts instead of the mariadb ebuilds. Here is what I did that led me to think the init scripts weren't being installed: 1. I upgraded to dev-db/mariadb-10.4.6 and the init script failed to work. 2. I decided maybe the upgrade process messed up somehow so I removed dev-db/mariadb-10.4.6, manually deleted the init.d/mysql and conf.d/mysql files and then installed dev-db/mariadb-10.4.6 again. 3. The init scripts were not installed after that and because I wasn't aware that the mariadb ebuild didn't handle the init scripts, I assumed there was an issue with the ebuild. 4. I restored the init.d/mysql and conf.d/mysql files from a snapshot of my btrfs root file system. 5. I then spent a while trying to figure out why the init.d/mysql file wouldn't work. I thought maybe the mysqld file had moved, was renamed to mariadbd instead and such but it turned out the binary was in the same place and mariadbd is a symlink to mysqld so that is all good. Then I figured out the failure was running the my_print_defaults binary and for a while I couldn't find the binary so I assumed that it was no longer installed so I looked online and built a new get_config() function to read the contents of the mysql config file and then the mysql init script worked just fine. 6. I started filling out a new bug report and in the middle of that I thought I should run "locate my_print_defaults" after running updatedb to see if the file existed elsewhere. Turns out that it did and all I needed to do was update the path to the program in the get_config() function. So I ended up (in hindsight) wasting time doing a lot of pointless things to get the new version of mariadb to work when I just needed to change the path to one binary in the init script.
