I have to introduce the post stating that I’m not a MySQL user; this site and the xine bugzilla both run on PostgreSQL, and similarly PostgreSQL is what holds the symbol collision database on my box. So if I feel critical of MySQL, well, I am. I’m not really much interested in improving it either, but I don’t want just to shitspread them, so my assessment will be as objective as I can be.
I’ve been looking at the buildsystem of MySQL to help Jorge with the infamous Amarok 2 problem which is making it unavailable on AMD64 and other architecture. I have to say that I do blame a bit the Amarok guys (as much as I love them) because they should probably have pushed MySQL devs to handle the issue before they hit stable; but well, what is done is done, and it’s time to handle it.
The problem is that Amarok tries to use MySQL Embedded in a shared library; shared libraries on AMD64 need to be built with PIC code, and of course MySQL Embeded is not built that way as it only provides static archives to link against. So what is needed is for MySQL to build a shared library copy of MySQL Embedded so that it can be linked in the Amarok engine library.
This is not something tremendously exotic to do, especially for Sound and Video we’ve been converting packages to install shared libraries for quite a while, and not just in Gentoo, but most distributions out there. When libtool is present, this usually gets quite easy since you just have to change some names around to make sure that instead of just building the archives, libtool is used to build the whole library, and there you go. For MySQL is not even vaguely that easy.
The problem is that the MySQL Embedded code seems like it was put there on a customer’s request, and as long as it worked for them, the whole thing was fine as it was; it shares part of the code with MySQL proper but not all of it, and the shared sub-modules (which are installed as separated static archives by MySQL right now), are not self-sufficient, as they require cyclic linking of dependencies.
The result is that to actually have the thing working, it’s likely that there will be some change in both the buildsystem’s interface, as well as some changes in the number and type of installed files; while this will likely also solve part of the code duplication problem that I found some time ago, it’s very unlikely that upstream would accept that for their main sources right away.
While MySQL is using autoconf and automake for the base of their build system, they are not only using lots of custom rules for the makefiles, they are also using some “strange” methods to add source files to target in particular cases (rather than using AM_CONDITIONAL) and also making use of knowledge against discovery which makes it a bit more difficult to find what is asking for what.
So where is this post going? Well, it’s just a way to ask users to understand why we haven’t fixed the problem yet; as for why we cannot just hack it around like it seems other distributions have done, the answer is that we do prefer to avoid those hacks since they are, well, nasty. And our users expect better from us, even when that means that it takes months to get a package in an architecture because the only way to build it there is to use a nasty hack.