mysql-proxy on ubuntu (and debian)

il corra walks you through building mysql-proxy for ubuntu.

il corra ยป mysql-proxy on ubuntu 7.04 feisty
First of all, there is not a packetized mysql-proxy for Ubuntu, so the only way to install it is to build it from the source


Which is great. But I'd like to take this opportunity to tell people that I've actually been working on packages for debian/ubuntu. They're almost ready to be released into the wild (I'm waiting on an almost non-related event) If you'd like to play with the packaging stuff before then, check out http://launchpad.net/mysql-proxy

I'll be sure to let everyone know when the packages themselves are in an APT repository.


0 comments
Tags: db code dpkg

Why I hate YUM

I really hate YUM, the crappy-ass apt wanna-be that all the non-Debian distros wet themselves over. Yes, it's better than what they had before, which was NOTHING. But it is absolutely inexcusable that, when apt was already available, powerful and quick, that they wrote YUM. Not because I think everyone has to use my favorite toy, but because it's a worse tool. It's it's slower, it's stupid and it gives terrible feedback.


Let's start with today's beef. I tried to do this:
yum install libselinux-devel
on a just-installed Fedora 7. What I got was this:
Transaction Check Error:
file /usr/share/man/man8/matchpathcon.8.gz from install of libselinux-2.0.14-4.fc7
conflicts with file from package libselinux-2.0.13-1.fc7
file /usr/share/man/man8/selinux.8.gz from install of libselinux-2.0.14-4.fc7
conflicts with file from package libselinux-2.0.13-1.fc7

Tell anybody what the problem is? First of all, has anyone ever tried installing this package?

It turns out, what it's trying to do is install the x86_64 and the i386 version of this package, and each one of those packages want to install those manpages. It seems fairly common to me that people might want to install this package on a 64-bit server. Why does it install the 32-bit lib? Why do the packages conflict? And why does the error message suck so bad?

Speaking of terrible error messages. Try this:
yum install kernel-dev
Wait, you might exclaim, being a RedHat person, this isn't a Debian system, we name our packages -devel. Quite true, my bad. Except what does YUM tell me?


Loading "installonlyn" plugin
Setting up Install Process
Parsing package install arguments
Nothing to do
Hm. Does that mean the package is already installed? Is it up to date? Or do we not even have a package named kernel-dev? Here's another way to do the same thing:



mtaylor@qualinost:~$ sudo apt-get install kernel-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package kernel-dev
Look at that! E for error, and then it shock tells me what the problem was.

The work has already been done! If you don't want to use APT, that's fine, you could at least look and see what it gets right and then improve on it! I mean, that's the way this whole Free Software thing is supposed to work, isn't it? Granted, maybe having to specify YUM repositories in chunks of XML is an improvement, and maybe I'm not seeing all the wonderful ways in which this is better than the crappy old APT from Debian.

But I don't think so.
0 comments