MariaDB 5.2.2 RC was released a few weeks ago, and last night I finally upgraded my workstation to have a look. I had to perform several APT related steps to upgrade, so these notes are more a commentary on apt(-get) than MariaDB itself (more on that later) and I'm mostly writing this down for future reference, should I need to do this again for the next upgrade.
The MariaDB binaries are built by the automated build and QA system that Kristian has set up. (Kristian is also famous for the MySQL pushbuild system used internally at MySQL/Sun/Oracle and many of us agree a certain baseline quality in MySQL 5.1 and now MariaDB is much thanks to his personal efforts!) The MariaDB BuildBot's spit out both a source tar file, binary tar files for different Linux platforms, Windows zip file, Sparc binaries, and also deb and rpm packages.
The MariaDB download page doesn't yet provide actual APT or yum repositories for easy installation on Linux systems though. The OurDelta project is trying to provide this service, but it is usually lagging one or two releases behind, and what's worse, it doesn't have MariaDB 5.2 releases at all.
Kristian however did share a simple script from which I could easily create my own MariaDB 5.2 repository. For future reference, I'm saving it here in case I need it again before MariaDB starts offering an official repository.
How to create your own MariaDB APT repository
- Download MariaDB deb files into local directory. Make sure to get the correct distribution and 32 vs 64 bit version.
sudo apt-get install reprepro$ cat conf/distributions
Origin: MariaDB
Label: MariaDB
Codename: jaunty
Architectures: i386
Components: mariadb
Description: My MariaDB Repository
(I skipped the SignWith since my GPG key is on another laptop.)for i in `find /home/hingo/doawnloads/MariaDB_debs/ -name '*.deb'` ; do reprepro --basedir=. includedeb jaunty $i ; donesudo echo "deb file:///home/hingo/hacking/MariaDB_apt/ jaunty mariadb" >> /etc/apt/sources.list
Installation and comments on APT
Some time had passed since I configured any apt repositories on a workstation, so this was the most difficult part of installation. Even if I'm quite fluent in using the command line, I'm actually a big fan of Graphical User Interfaces. I like to use a GUI whenever possible, I prefer it myself, but I also want to know how to use the GUI since that is what I need to teach my family members who all use Linux too (including 2 year old son and 60+ parents).
On Kubuntu we have KPackageKit to install DEB packages. Like many other software in KDE recently, there have been some weird choices in the interface that make it difficult to guess where to click to add or remove a package. But in principle it is quite usable, if just the icon's were easier to understand. Yet, if I compare this to the gurpmi/urpmi package management system Mandrake had in the late 90's, several things could be easier to use.
- If I have a local directory with deb files, why does it have to be a proper APT repository at all? I should be able to just add the directory to
/etc/apt/sources.list. Apt-get could just read and index the deb files directly, there's no reason to have aPackages.gzfile. - Why is the entry in
sources.listnot just a simple url? Why do I have to add"jaunty"and"mariadb"to it? First of all, Kubuntu should itself know that it is a"jaunty"system. Also the"mariadb"part is redundant since most of the time you just use one "component" per entry. If I just gave it a URL, apt-get should be able to figure out the rest from there. - In KPackageKit it wasn't obvious I could even add a local directory at all. I first copied my MariaDB repository to my web server on localhost and gave it that url. But if you look at the instructions above, you actually can use a
file:///url too. - When I finally proceeded to install mariadb-server, KPackageKit told me I first needed to uninstall mysql-server. This is because mariadb-server replaces mysql-server, so the deb
"Conflicts"with mysql, you cannot have both at the same time. Luckily I didn't actually do what KPackageKit told me to. Uninstalling MySQL first could have unintended consequences, for instance many other packages depend on the mysql client and could automatically have been uninstalled too. Instead, I left KPackageKit behind and just did sudo apt-get install mariadb-server, which properly replaced mysql on the fly, without any need to uninstall anything first.
...in any case, the steps between downloading perfectly nice debs and actually installing them with a convenient apt-get install mariadb-server are unnecessarily complex, there should actually not be any such steps. Also I've never realized why the GUI tools often are less intelligent in solving depends and conflicts than apt-get itself, why are they not just wrapping around what apt-get already does well???
Running MariaDB 5.2
The actual installation of MariaDB went fine. I could immediately login and view my databases:
$ mysql -u root
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 6
Server version: 5.2.2-MariaDB-gamma-mariadb86-log (MariaDB - https://mariadb.com/)
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
...
| world |
+--------------------+
21 rows in set (0.00 sec)
MariaDB [(none)]> use openlife;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [openlife]> show tables;
+--------------------------+
| Tables_in_openlife |
+--------------------------+
| access |
...
| wiki_name |
+--------------------------+
67 rows in set (0.00 sec)All commands and filenames are identical to MySQL, but the prompt reveals I'm connected to a MariaDB server rather than the original MySQL. I'm able to SHOW my databases, USE the openlife database and view tables in there.
After the installation my workstation became sluggish. With top I saw that mysqld_safe, which is the script used to start and keep alive the mysqld server process, was using 100% of one CPU core. Ok, that looked bad. But after some googling and verifying with pstree, it turns out this is the old mysqld_safe from the original mysql 5.0.x version I just replaced, that wasn't properly shut down and remover. People upgrading between MySQL 5.0 and 5.1 have experienced it too. It's still alive and desperately trying to restart the mysql binary that is not there anymore. Just killing the process or restarting your computer makes it go away. So it wasn't a MariaDB bug anyway, but I still filed a bug here. Maybe we could at least create a knowledgebase entry of it.
- Log in to post comments
- 8359 views
This would make a good KB article
Good work Henrik, now go make it an article in the Knowledgebase!
This would NOT make a good KB article
I disagree. We could spend the same amount of time and actually write a script that creates apt repositories (and another amount of time for yum). Then nobody needs to know this stuff, which is the way it should be.
The only discovery here that deserves to be in the KB is that KPackageKit suggests I should uninstall MySQL, which I'm pretty sure is a bad idea.
Why don't you use dpkg
Why don't you use dpkg directly instead of all the reprepro/apt stuff? Works just as well.
Re: Why don't you use dpkg
Well, for MariaDB installation
dpkg -iworks well (I hear), but in the general case it doesn't. If the mariadb-* packages I'm installing depend on some other packages I'm still missing, then dpkg will not automatically fetch them from whatever repository they are in.But in this case, it was also a learning experience. I've proven that producing the apt repository is not a lot of work, so now we could spend a little effort in MariaDB to actually do that. Then we can forget dpkg :-)