[Mageia-dev] Replacing mysql with mariadb

Colin Guthrie mageia at colin.guthr.ie
Thu Dec 1 21:12:57 CET 2011


'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).

> 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


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/


More information about the Mageia-dev mailing list