diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-December/010073.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-December/010073.html | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-December/010073.html b/zarb-ml/mageia-dev/2011-December/010073.html new file mode 100644 index 000000000..daa24f0d1 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-December/010073.html @@ -0,0 +1,177 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Replacing mysql with mariadb + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Replacing%20mysql%20with%20mariadb&In-Reply-To=%3C201112012122.44038.alien%40rmail.be%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="010072.html"> + <LINK REL="Next" HREF="010078.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Replacing mysql with mariadb</H1> + <B>Maarten Vanraes</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Replacing%20mysql%20with%20mariadb&In-Reply-To=%3C201112012122.44038.alien%40rmail.be%3E" + TITLE="[Mageia-dev] Replacing mysql with mariadb">alien at rmail.be + </A><BR> + <I>Thu Dec 1 21:22:44 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="010072.html">[Mageia-dev] Replacing mysql with mariadb +</A></li> + <LI>Next message: <A HREF="010078.html">[Mageia-dev] Replacing mysql with mariadb +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#10073">[ date ]</a> + <a href="thread.html#10073">[ thread ]</a> + <a href="subject.html#10073">[ subject ]</a> + <a href="author.html#10073">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Op donderdag 01 december 2011 21:12:57 schreef Colin Guthrie: +><i> 'Twas brillig, and Maarten Vanraes at 01/12/11 19:53 did gyre and gimble: +</I>><i> > Op donderdag 01 december 2011 10:32:14 schreef Colin Guthrie: +</I>><i> >> 'Twas brillig, and Maarten Vanraes at 01/12/11 08:05 did gyre and gimble: +</I>><i> >>> The way I see it, there are 2 possibilities: +</I>><i> >>> A. I remove the mysql-client, libmysqlclient, mysql-common and assorted +</I>><i> >>> packages from mysql, and provide them with mariadb, since +</I>><i> >>> libmysqlclient is drop-in replacable (same library ABI and such), +</I>><i> >>> there is not 100% requirement of rebuilding all libmysqlclient +</I>><i> >>> dependant programs. +</I>><i> >> +</I>><i> >> I think that rather than just provide them, it would make sense to use +</I>><i> >> the update-alternatives system. +</I>><i> >> +</I>><i> >> It's going to be quite hard to rip out one package and drop in the other +</I>><i> >> without some problems so it would be nice if we could install both at +</I>><i> >> the same time and switch between them with a simple update-alternatives +</I>><i> >> plan. This would perhaps facilitate easier testing too (i.e. easy to +</I>><i> >> compare one to the other and switch about etc.) +</I>><i> >> +</I>><i> >> In the initial stages you can make MariaDB have a higher priority in the +</I>><i> >> update-alternatives setup to encourage more usage/testing coverage. +</I>><i> >> +</I>><i> >> While I appreciate it's extra effort for you and QA, I think this is the +</I>><i> >> best route forward for mga2 at least. +</I>><i> >> +</I>><i> >> Col +</I>><i> > +</I>><i> > i don't think the update-alternative is usable for the client parts at +</I>><i> > least +</I>><i> > +</I>><i> > you will need to build programs with mariadb mysqlclient.so, so that +</I>><i> > doesn't work as alternatives, so that means the whole common and mariadb +</I>><i> > client is required too +</I>><i> +</I>><i> Hmm, I'm not sure I understand why it doesn't work? Why can't +</I>><i> mysqlclient.so itself be a symlink via alternatives? Does the linker +</I>><i> bork perhaps? +</I>><i> +</I>><i> If both packages provide the same virtual provides ("mysql-devel") then +</I>><i> it should be pretty simple to make the one provided by mariadb to be the +</I>><i> preferred one (not 100% sure how that works, but I think it's possible). +</I> +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. + +><i> > so the only thing that can be alternativified would be the server, which +</I>><i> > is not really necessary to be alternivified anyway, since you can just +</I>><i> > install mariadb for that and remove mysql. +</I>><i> > +</I>><i> > you have to remember how mariadb works, it's like us, they take mysql +</I>><i> > from upstream, and put patches on it. +</I>><i> > +</I>><i> > the client doesn't have any major feature changes, it just has some +</I>><i> > improvements for if you'd use mariadb and some bugfixes. ( mariadb server +</I>><i> > with mysql client, works also perfectly, allthough NOT on the same +</I>><i> > server, due to my.cnf ) +</I>><i> > +</I>><i> > but however you look at it, client and common part of mysql will need to +</I>><i> > be obsoleted. +</I>><i> +</I>><i> Thinking about all the issues, it will be pretty complicated to fully +</I>><i> alternativify it (all the conf files etc. would be a bit of a pain) +</I>><i> +</I>><i> Not sure how to handle it, but I don't think obsoleting the existing +</I>><i> mysql packages is a great idea... I guess just another round of testing +</I>><i> after it hits the main repo might be enough? Can you just make the +</I>><i> package provide the same things as the mysql ones but with a higher +</I>><i> release number? That's how the systemd-sysvinit package was forced on +</I>><i> people over sysvinit... perhaps the same approach here would force some +</I>><i> testing and to revert all we need to do is bump the mysql rel up two +</I>><i> notches and it'll become the default again? +</I>><i> +</I>><i> Col +</I> +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. +</PRE> + + + + + + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="010072.html">[Mageia-dev] Replacing mysql with mariadb +</A></li> + <LI>Next message: <A HREF="010078.html">[Mageia-dev] Replacing mysql with mariadb +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#10073">[ date ]</a> + <a href="thread.html#10073">[ thread ]</a> + <a href="subject.html#10073">[ subject ]</a> + <a href="author.html#10073">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |