Everything is a Freaking DNS problem

I always install MySQL Server using the --noscripts option to rpm. I then manually do the stuff the scripts would have done when I'm ready.

Hi Kris,

How complex is it to manage your own repository?
I'm asking sincerely, since this is not something I ever did.

It seems to me (let me know if I'm wrong) that it's not less complex than having MySQL installed using tarball.

Neither solution is pretty nor ideal. I'm not sure, then, that tweaking your repository (how much damage is done if something goes wrong there?) is any easier.

I'm pretty certain that an expert sys admin would say managing your own repository is a piece of cake. An expert MySQL DBA has little trouble with installing from tarball.

Best to compare on non-expert level.

Regards,
Shlomi (Open-Ark)

Yes and no in response to your comments.

There's nothing inherently wrong with using packages, but they need to do what you want. Sometimes, however, the original packaging design may do things you don't like and that's not helpful.

Also in an environment where you have more than one database instance running on the same host, most rpm packages are "broken", assuming that there is only one instance and only one package. That is not always true.

I work in an environment where we have multiple instances. You can work around the packaging problem if all instances run the same version, but if you want to first test a new version while running an older version, that's hard with most rpm packages. I'm not sure if apt packages are better.

The Linux kernel packages seem to be more suitable: you can install more than one package at once, and each one is isolated. Obviously you can't run more than one kernel at once, but running more than one mysqld is easy as long as you put your datadir somewhere different for each instance.

Then if you're looking at upgrading 5.0 to 5.1 be aware of some of the silly hoops you have to run around: you need to start mysqld 5.1 to run the 5.1 mysqlcheck to check which tables need upgrading, and in theory to do this you have to downgrade again back to 5.0 to do the dump, and upgrade again to import those dumps back in. Silly. If you can only have one version of the mysql package installed at once that becomes frustrating.

RedHat and MySQL rpms also insist on starting a MySQL instance when the package is installed. That's not sometimes very helpful if you're going through an install process, or want to "tweak" certain things before putting the server live (a slave will immediately try to talk to the master and start replicating), yet there's still no fix possible to tell the package: please don't start me while installing or upgrading. Not hard to do and possibly not an issue for a lot of people, but for some of us this behaviour is not ideal.

So in general I agree. Packaging is good, but I think that the MySQL packaging I've seen is not intended for people who work in a slightly more complex setup. However, we are the people who really use MySQL and actually need these features.

I'm still pondering over whether to go back to mysql binary tar balls and use something like the MySQL Sandbox scripts (or something similar) to manage multiple instances. This software actually works quite well, even if the setup is a little unconventional for managing production or development MySQL instances.

In the end I'd like the packages to install into a separate location, and it to be possible to have multiple versions installed at once, and then have some simple way to manage more than one instance and to be able to switch between those instances that are running on the same box.

However, I see that changing from the current practice is probably too much, which leads me to assume I'll have to come up with my own adhoc "different" solution. You may do the same thing using your solution which different again from mine.