[Mageia-dev] Replacing mysql with mariadb

Thu Dec 1 21:22:44 CET 2011

Op donderdag 01 december 2011 21:12:57 schreef Colin Guthrie:
+> 'Twas brillig, and Maarten Vanraes at 01/12/11 19:53 did gyre and gimble:
+> > Op donderdag 01 december 2011 10:32:14 schreef Colin Guthrie:
+> >> 'Twas brillig, and Maarten Vanraes at 01/12/11 08:05 did gyre and gimble:
+> >>> The way I see it, there are 2 possibilities:
+> >>> A. I remove the mysql-client, libmysqlclient, mysql-common and assorted
+> >>> packages from mysql, and provide them with mariadb, since
+> >>> libmysqlclient is drop-in replacable (same library ABI and such),
+> >>> there is not 100% requirement of rebuilding all libmysqlclient
+> >>> dependant programs.
+> >> 
+> >> I think that rather than just provide them, it would make sense to use
+> >> the update-alternatives system.
+> >> 
+> >> It's going to be quite hard to rip out one package and drop in the other
+> >> without some problems so it would be nice if we could install both at
+> >> the same time and switch between them with a simple update-alternatives
+> >> plan. This would perhaps facilitate easier testing too (i.e. easy to
+> >> compare one to the other and switch about etc.)
+> >> 
+> >> In the initial stages you can make MariaDB have a higher priority in the
+> >> update-alternatives setup to encourage more usage/testing coverage.
+> >> 
+> >> While I appreciate it's extra effort for you and QA, I think this is the
+> >> best route forward for mga2 at least.
+> >> 
+> >> Col
+> > 
+> > i don't think the update-alternative is usable for the client parts at
+> > least
+> > 
+> > you will need to build programs with mariadb mysqlclient.so, so that
+> > doesn't work as alternatives, so that means the whole common and mariadb
+> > client is required too
+> 
+> Hmm, I'm not sure I understand why it doesn't work? Why can't
+> mysqlclient.so itself be a symlink via alternatives? Does the linker
+> bork perhaps?
+> 
+> If both packages provide the same virtual provides ("mysql-devel") then
+> it should be pretty simple to make the one provided by mariadb to be the
+> preferred one (not 100% sure how that works, but I think it's possible).
+
+yes, this is what i first said to Anssi too when i asked him about it. but the 
+problem would be that other progs would be built against mysql and just drop-
+in replaced mariadb shared libs.
+
+Either it works perfectly, in which case we can just use libmysqlclient from 
+mariadb, or it doesn't work, and we shouldn't use the libmysqlclient from 
+mariadb anyway.
+
+then there is the my.cnf file, which contains extra [mariadb] for mariadb, 
+which is ignored when using mysql, but is used by both client and server.
+
+and lastly upstream told me that while mysql clients works with mariadb 
+server, it might not work (untested by upstream) to use mysql client on a host 
+with mariadb server, due to the my.cnf .
+
+thus since mariadb mysqlclient works with both mysql and mariadb the best way 
+is always to have mariadb clients even if you use mysql server. that is no 
+problem.
+
+> > so the only thing that can be alternativified would be the server, which
+> > is not really necessary to be alternivified anyway, since you can just
+> > install mariadb for that and remove mysql.
+> > 
+> > you have to remember how mariadb works, it's like us, they take mysql
+> > from upstream, and put patches on it.
+> > 
+> > the client doesn't have any major feature changes, it just has some
+> > improvements for if you'd use mariadb and some bugfixes. ( mariadb server
+> > with mysql client, works also perfectly, allthough NOT on the same
+> > server, due to my.cnf )
+> > 
+> > but however you look at it, client and common part of mysql will need to
+> > be obsoleted.
+> 
+> Thinking about all the issues, it will be pretty complicated to fully
+> alternativify it (all the conf files etc. would be a bit of a pain)
+> 
+> Not sure how to handle it, but I don't think obsoleting the existing
+> mysql packages is a great idea... I guess just another round of testing
+> after it hits the main repo might be enough? Can you just make the
+> package provide the same things as the mysql ones but with a higher
+> release number? That's how the systemd-sysvinit package was forced on
+> people over sysvinit... perhaps the same approach here would force some
+> testing and to revert all we need to do is bump the mysql rel up two
+> notches and it'll become the default again?
+> 
+> Col
+
+i don't really want to mess with versions, the versions which are there atm, 
+are the versions, that they are exactly the same, is because they ARE the same 
+and the most up2date. donno if bumping release would work.
+
+but then obsoleting is not a big thing, worst case, we drop mariadb and 
+resubmit mysql and problem solved.
+
+and furthermore, if we do provide mariadb, we'll have to obsolete mysql 
+eventually. why not complete test it when we have the chance? if we complete 
+this testing before 9 dec, we can easily switch back without any real issues 
+if needed.
+