Michal Hrušecký

After some discussions which happened on mailing list lately, I decided that server: database repository can use some more adjustments. Some people complained about changes I introduced with MySQL 5.1. One point of view is that using factory version on production server is a bad idea but on the other hand, where would you get something newer for your old openSUSE to let it survive a little bit longer before upgrade to newer version? I'd like to introduce following repository scheme which should solve these problems...

server: database: STABLE

This repository will contain last officially released version of some server database related packages. Purpose of this repository will be mainly to provide new stable packages to users of old distributions and possibly as a repository with minor fixes which are too minor to get to the official update.

server: database: FACTORY

Packages in this repository will be intended for the next version of openSUSE release. They should be quite stable but generally much less tested then packages from STABLE repository. Version updates can occur and sometimes something can be a little bit broken.

server: database: UNSTABLE

As name suggests, this repository is mainly for testing. It's purpose is to contain highly experimental packages not intended for next openSUSE release. It may contain alpha or beta version. Purpose is to be prepared for possible problems when package became stable and we would like to include it in openSUSE. Or maybe to test some highly experimental settings of existing packages.

Summary

Now you may choose by yourself how stable/new database you want. Well not really now as I created these repositories just today and I didn't put all packages in them yet and as Build Service is currently heavily loaded I think it will take some time to get everything built... But you can be prepared and you can know what you can expect in near future. And you probably also can add repository of your choice already

Do you know what Geeko Builder is? No? So let's talk about it a little bit. Everybody probably knows who Geeko is. Geeko is that chameleon in SUSE logo. And what is Geeko Builder? It is a web application where you can dress up your Geeko. You can choose where to put him, what he should wear and few similar things. One disadvantage I found is that you have to choose from limited number of items and backgrounds available already in builder and you can't upload your own background or item. After creating your Geeko, you can download your picture in big resolution and use it as a background or as an avatar. Other interesting thing is that after saving your Geeko, your image will appear in gallery where people can vote for it. And the best pictures will win some price in the end according to the site.

As an example, I'll show you my Geeko and tell you something about it. When I was child, one of my favorite cartoons was Teenage Mutant Ninja Turtles. So I designed my Geeko with one of that turtles in mind. Well, with limited items I creted Leonardo like Geeko.

While I was playing with MySQL I realized that most of the problems users can run into are caused by using non-distribution configuration file for MySQL. RPM wouldn't overwrite original file if user has manually altered it. And it can became source of problems for users. Sometimes it may not be obvious that they should merge thier configuration file with distribution one to fix errors. While I was discussing this with my colleagues, we came to the conclusion that some tool for managing configuration files may be handy. Something what will warn users about possible conflicts, help them solve them and maybe more.

Other distributions already has something like this. In Gentoo there are even two tools for this thing. One is called etc-update and the second one is dispatch-conf. While discussing these tool we also came accross some disadvantages these tools have. Well, in the end, I filled up feature request. So some details can be found there. This blog entry should just attract more attention to this feature.

Other purpose of this blog entry can be to mention some completely unofficial things and dreams. As you may see, I already collected some feedback. And I will try to keep all relevant informations on openfate. So after collecting some opinions, the most important part would be implementation, don't you think? As probably everybody else, I'll be happy if somebody will be interested enough to start real project. But I put it on my todo, I'm thinking about it and I'll try to take a better look on possibilities how to implement such a thing in future (not sure how distant future, got exams in school now). Any new idea is off course welcome and everything I'll find out will be posted on openfate page.

Last thing, let's mention link for feature#306411 again. As stated before, all relevant informations will be there.

Some of you may already notice, that in Build Service, there are already available rpms for new MySQL 5.1. Currently I think that in openSUSE 11.2 will be some 5.1 version of MySQL. So it may be interesting to tell our users what will change and how. Most of these changes are reflected in README.SuSE, but frankly - who reads READMEs?

Changes

Plugins

One of the new features in MySQL 5.1 is support for plugins. So some of the storage engines will be now shipped like that. Following plugins will be available:

• archive
• blackhole
• federated
• example

As you can see, InnoDB will be still compiled as internal part of MySQL. If you are upgrading from version 5.0.X or if this is your first installation of MySQL 5.1, all plugins will be enabled by default and you can disable them manually later (see manual). All these plugins are installed by main mysql rpm so you don't need to install anything special. And if you don't like them, you can disable them easily and completely

With this change you need to remove skip-federated option from your my.cnf file if you have changed it manually. This option was there by default in previous versions of MySQL. But if you are installing MySQL for the first time or if you didn't touch your configuration file, everything should be ok.

File locations

There are going to be some changes in files locations too. Most of them was made in default configuration file so if you are experiencing problems and you have made some manual adjustments to your /etc/my.cnf, try to merge this file with /etc/my.cnf.rpmnew.

First of them is that mysql socket file and pid file were moved by default from /var/lib/mysql to more reasonable location ( /var/run/mysql ). Second change is that mysql log file is again back in /var/log. These changes should make MySQL more LSB friendly and help people with their MySQL administration. All these changes can be reverted by changing MySQL configuration file so if you don't like it, you can move them anywhere you want

BerkeleyDB

Other important change is that MySQL no longer contains BerkeleyDB as storage engine. There is no fix for that and if you used it before, you have to migrate your data to different storage engine.

MySQL Upgrade Log

Last thing you may find useful is that if you missed messages displayed during automatic MySQL database upgrade, you can find them from now on in /var/log/mysql_upgrade.log.

Summary

Just summarization of what you can expect. You wouldn't be able to use BerkeleyDB any longer. And if you are experiencing any problems, it's probably because you changed your configuration manually so solution is to replace /etc/my.cnf by /etc/my.cnf.rpmnew