[Mageia-dev] Replacing mysql with mariadb

[Maarten Vanraes]

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.