As I promised a week ago, I’m publishing results of my little MySQL survey. Question that people (including me) are probably the most interested in is what variant(s) of MySQL are people using. No big surprise is that the most used variant (89%) is MySQL Community Server from Oracle. It’s well known default, people know what to expect and administrators golden rule is don’t touch it if it works. And other variants build on top of it anyway.
Second place (20%) belong to MariaDB. That is answer I also kind of expected. MariaDB guys are verbose and visible. At least I saw much more people talking about MariaDB then about Percona. Part of it might be that they position themselves as kind of MySQL competitor. Oracle is big controversial company. Sometimes we hate them (they killed OpenOffice!), sometimes we love them (btrfs is great!). So I can imagine regular users getting angry with Oracle and switching to the competitor. And there was a period of time in history when we all were unsure about what Oracle will do to the MySQL and MariaDB was there for us. Some people can also have some valid reasons. Like the need for one of the included storage engines.
What surprised me was how little people use MySQL Cluster included in the distribution. 4 people responded that they use MySQL Cluster and only two of them use it from main repository. Cluster uses same amount of people as people using Percona which we don’t have in our repositories at all! The outcome from this is that I’ll probably drop MySQL Cluster from main distribution and keep it only in obs for now. This change will help me concentrate more on variants that people use. But MySQL Cluster will be still available in obs in it’s latest version.
I’m not planning inclusion of Percona, but if anybody is interested, it should be pretty easy to put it to obs using templates I have for MySQL.
From the rest of the results, it’s apparent that unstable repository is not known and that plenty of responders have some suggestions for default MySQL configuration and they are keeping them to themselves! So if you are one of them, let me know you suggestions. Ideally by sending me configuration snippet everybody can benefit from 😉
In the end I would like to thank all participants for their responses, it will help me concentrate on things you are interested the most and improve overall presence of MySQL in openSUSE Build Service. And of course, any comments are welcome and whole results can be seen on separate web page mentioned bellow 😉

In openSUSE we’ve got currently MySQL Community Server, MariaDB and MySQL Cluster. From all of these we have even multiple versions. Although these packages are different, they are quilte similar. So I’m handling them in a little bit special way.
When I was adding MariaDB I knew that packaging will be quite similar to the MySQL Community Server. So I took some parts of .spec file away into separate files so I can sync them easily and left only package dependent parts in .spec files. Later on, I created special git repository and few scripts to handle patches and patch sharing among these variants. And lately I automatized tre rest of the manual syncing I was diong. So today I want to present how do I do MySQL packaging today. And that is also some tutorial on how you can modify these packages easily or even create packages for other variants like Percona 😉
Everything starts with one of my repositories on github. Let’s take a look at what it contains. Some scripts and few directories. Let’s start with directories.
First directory is named common and it contains several files. As you can guess, it contains code common to all MySQL variants. So you can find here build scripts, install scripts, rc script, few readmes and template for the spec file. Templates ends up with .in. All non-template files are later committed to the openSUSE Build Service as they are in the repository. Templates needs to be filled in first. For that I decided to use mustache. You can install it by running gem install mustache. But back to the packaging. We need some variant specific files, something to fill templates with and some patches, right?
For these reasons there are directories named after particular MySQL variant (for example mysql-community-server-56 or mariadb-53). Inside these directories are at least config.yaml file and series fil. But probably there is some more. config.yaml file is used by mustache to fill in the templates. So you can find here package names, descriptions, versions and such. Things that has to differ among all variants.
Apart from these, you can also find some .cnf files in variant specific directories. These are configuration files to be included. This way even if you modify your /etc/my.cnf, these snippets can get updated (if you don’t modify them as well). Here is also place for some contribution – you can send me just few snippets from my.cnf, that will improve default configuration 😉 Or create packages with new plugins and them register automatically here.
Last file in the variant directory I spoke about – series file and the last directory I havn’t spoke about yet – patches have something in common – they are used for patching. series file contains a list of patches to apply. And patches directory contains these patches. How it works is described in my other github repository. Basically the point is to use few scripts so I have to maintain just series file outside of .spec file. Then there are scripts that will fetch patches, pack them up and during build apply them. No need for me to take some extra care.

Last time I described how to contribute quite to any package in openSUSE Build Service. But I left out the most important part. I haven’t shown how to change anything. This time I want to show you, how to create patches, if you need them, easily. Let’s start start with package we checked out from obs. Creating patch for anything is different only in first few steps.
First we got to the directory where do we have the package checked out. We run

Hi, just another quick update about openSUSE @ ARM project. Yesterday I posted that I’m happy geeko because I have openSUSE chroot on my ASUS Transformer. Several people were excited and wanted to try it too, even though I posted that it is highly work in progress. Ok, so to satisfy these curious readers, I’ll share my chroot. What is there and hopefully working is zypper and osc, so you can install new packages as we will fix them and you can help with fixing broken ones. But I would recommend not to use any of this on your internal memory. At least on external SD card you are not afraid to destroy or ideally on some network filesystem.
How it works? You need some machine you have root on and at least a little bit decent busybox. Then just unpack content of this archive to your SD card, make adjustments to the linuxchroot script if needed and run it from terminal. You should end up chrooted into openSUSE. If not, I warned you that this is not even in alpha state, so check what script is doing, why is it failing and fix it 😉 Comments are welcome, support requests not so much 😀 And I take no responsibility for anything and everything is up to you 😉 So this is definitely not for end users.

I promised that I’ll write a post about how you can contribute. There are several ways how to contribute to MySQL, but most of it means modifying packages. And as everything in openSUSE is built using openSUSE Build service, first post will be actually pretty general obs and osc howto. In the next posts, I’ll go deeper into specific details of MySQL packaging.

Find the package

If you want to play with any package in openSUSE Build Service, you need to have a Novell login and preferably the osc command line client for obs. You can do most of the stuff from web as well, but this way is more comfortable 😉 So let’s say that we want to play with MariaDB. First we have to find package we want to update. This can be easily done on the web. Just take a look at packages at server:database repository. mariadb is the version currently included in the Factory. If you want to update bleeding edge version, these are named usually something like mariadb-53 for 5.3 branch or mysql-commmunity-server-56 for MySQL Community Server 5.6 branch. So basically if package name doesn’t contain version, it’s package for factory, if it does, it is just for people wanting something that is not in Factory yet (or already).

This is going to be just a brief blog post with one important image. You probably all already know that there is bunch of people in openSUSE community who are working on getting ARM supported by distribution. And you probably already seen many blog posts about how great it is working. Well this is one of them. I’m happy owner of ASUS Transformer machine. As a geek I have root on my android machine. And since not long time ago, I also had a Debian chroot there to be able to run my favorite applications. But not any more. I replaced my Debian chroot with openSUSE one and now I can use zypper happily and forget everything about apt-get.
How did I did that? I started with a simple package in obs, changed BuildRequires to the set of packages I wanted to have, run osc build armv7l standard and after osc created chroot for me, I just took it away. And fixed few things after switching to it on my Transformer. I’m still missing some packages, but hopefully they will be available soon 😉

Looking at still progressing survey(currently more than 50 responses), I still see, that nobody uses server:database:UNSTABLE repository in openSUSE Build Service. So I have an idea to drop it completely – whole repository – and move packages that are only there (like MariaDB 5.3 or MySQL Community Server 5.6) to the server:database repository. This might make it easier for people to find these packages. But it has some downsides as well. Original purpose of UNSTABLE repository was to have it in name that this contains alpha/beta versions and that it may not work or worse. Once I will move it to the server:database repository, only distinction would be summary and package name. And who read the summary… I guess I will go for it and we will see. But if you have some strong arguments against, speak now, otherwise I will proceed in next few days 😉