[Mageia-dev] HEADSUP: mariadb available for testing

Fri Nov 11 00:17:47 CET 2011

Hi all,
+
+mariadb-5.5.15-0.mga2 should be hitting the mirrors soon (at cauldron 
+core/updates_testing). It's purpose is to be an alternative to mysql. for that 
+reason, mariadb packages provide also the similar mysql targets.
+
+mariadb is intended to be a drop-in replacement for mysql, it goes so far to 
+actually have the same files and ABI's as mysql. after looking at their forking 
+process (it's not actually a full fork, they start from mysql and then patch), 
+i've seen that it's actually very good for a drop-in replacement. There are a 
+few differences ( http://kb.askmonty.org/en/mariadb-versus-mysql-compatibility 
+) but they are minor. I've done a few minor tests with amarok, akonadi, drupal 
+and phpmyadmin (and of course mysql client).
+
+NOTE: mariadb provides actually most storage engines mysql provides as well, 
+but also the original and unpatched MyISAM and InnoDB engines from mysql. On 
+top of that, it has some extra storage engines. XtraDB, which is the drop-in 
+replacement storage engine for Innodb, is essentially an innodb with extra 
+patches from various sources, like google, facebook, etc... ( see 
+http://kb.askmonty.org/en/mariadb-versus-mysql-features )
+
+I've chosen to use mkrel 0 atm, because it's not a released version yet, I've 
+talked extensively to mariadb developers, and they mentioned that they did 5.3 
+and 5.5 in parallel, so that 5.5 should be released as beta pretty soon. When 
+i talked about our release schedule, they did mention that mariadb-5.5 should 
+be final before februari.
+
+My plan is as follows:
+1. provide testing package [DONE]
+2. clean up spec file from mysql and file some patches upstream [DONE]
+3. provide newer testing package when it's released as a alpha/beta
+4. if testing is satisfactory (not breaking buildsystem or mysql) submit to 
+core/release and get more testing.
+5. if final 5.5 release is on time, have mariadb into mageia2
+
+now there, we have a few options:
+
+considering that mariadb is essentially mysql + extra features, if we ship 
+both mysql and mariadb, we should ensure that normal users don't go from 
+mariadb to mysql. (if a storage engine would be used that's NOT in mysql, 
+suddenly a few databases might not work, even though the data is still there.)
+
+A. provide both but with vendor preference
+making sure one of them both is preferred should be ok, since they conflict 
+anyway, if a user installs the non-preferred one, she knows what she's doing.
+( I think a note could be added here for warning purposes )
+
+B. only use mariadb anymore
+=> That's the easiest and safest option...
+_IF_ mariadb works well. (which i'm sure we'll see in our testing)
+(IMHO, if it worked for libreoffice, i don't see why not for mariadb)
+
+
+any opinions? testings? problems?
+