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.
This reply’s more to do with amarok than mysql, except that this problem was the proverbial straw that broke the camel’s back, here.I’d had a growing realization that amarok is way heavy for the sorts of stuff I tend to use it for, and with KDE4, even many of the features I used it for are gone, tho maybe they’ll return… someday. The only thing I needed ruby for was amarok. With the KDE4 version, the only thing I need mysql for was amarok, and it’s a huge hassle because I have to hack the thing, adding -fPIC, tho since that’s all I use it for it’s not /that/ bad a hack.While I was at it I decided I wanted a player at the console (VT) too, so started looking at that, and then decided a detachable player, so I could kill all the clients and have the music server still playing, was useful. That got me looking at mpd (music player daemon) and its many clients, command line, curses based text-GUI, X based (qt3/4, gtk2), even web (apache) based.So that’s what I’m doing now, switching to mpd, with various clients I can attach or detach at will. If I’m already losing the amarok mini-player (the winamp skinnable part) and visualizations, much of what I used amarok for, I might as well, and altho it’s involving a bit of retraining myself, mpd will be far more flexible when I’m done in any case… plus even with multiple independent clients it’s still far lighter weight than Amarok.And, if I want visualizations, I still have kaffeine with goom, which was already good enough I’d choose to use it over amarok some of the time, and there are other visualization options using jack or pulseaudio among others, if I decide it’s worth the trouble. (And it’d /still/ not be much more heavyweight than amarok, tho more flexible.)I unmerged both the KDE3 and KDE4 versions of amarok yesterday after ensuring mpd and the ncurses and CLI clients worked, tho I haven’t yet tested the X clients yet nor run a –depclean so still have the mysql and ruby dependencies hanging around. But I’m not going to be worrying about Amarok or its heavy dependencies much longer. It’s mainly cleanup, now.Duncan
I’m using those hacks already xD
Duncan: actually, I’m also not using Amarok for quite a while now, and using mpd myself (I even “fixed build the other day”:http://git.musicpd.org/cgit… ). While I miss the collection as provided by Amarok, I also found the MySQL dependency a bit too much for a music player.The only reason why I’m working on this bug is because it’s autotools-related and I still like consider the Amarok team as friend, even though I seriously dislike the policies behind KDE lately.
IF they used sqlite instead of mysqlembedded…
How does sqlite compare with mysql embedded?
Not sure if SQLite was any better when it comes to the code, but at least one has to admit that SQLite has been developed with the idea of being used in process in mind.On the other hand, we already know that SQLite developers seem to be pretty bad at making things work for given development project for more than one release, which is what causes the “infamous Mozilla bug”:https://blog.flameeyes.eu/2… .
Yeah, I’m glad you’re working on the bug. I’m still CCed on the Gentoo bug now for much the same reason, intellectual and historic interest in the problem and its solution, not for any personal practical benefit.As for KDE, 4.2 is an improvement, but still nothing near 3.5 or even 3.1 in terms of actual practical usability from my perspective. But I keep hoping. Maybe by 4.3, or 4.5 at least. Encouragingly, it’s actually getting to the point it’s at least well enough runnable to start filing bugs on now. I guess that makes it finally beta quality. (shrug)Of course in my case at least some of it is that my viewport is larger than the card and driver’s OpenGL viewport handling ability (2048 px square, my desktop is 2400 px tall), so I’m /both/ missing a lot of the new eye candy /and/ all the practical functionality they haven’t seemed to have actually gotten around to reimplementing just yet.Also, some of it is simply learning a new way of working and rearranging the available components to fit my style, when the available components change as they certainly have.I still have faith a lot of it will come… over time… and probably helped when I upgrade my graphics card later this year so I can at least get the benefit of that, even if the functionality is still lacking.Meanwhile, 3.5 is still full functionality and I expect I’ll be on it for awhile, ’till 4.3 at least and very likely 4.5. I just hope they keep up with the updates as they promised. We’ll see.Otherwise, I honestly don’t see GNOME in my future, but maybe XFCE or something highly personal and customized, individual pieces of a bunch of stuff.(Yeah I know it’s partially OT for the post, but I’ve seen your musings on the KDE stuff in general in the past so fits the blog at least, and not having my own blog, I needed /somewhere/ to vent.)Duncan