Skip to content

# To not yum or to not apt-get?

MySQL Configuration Installation Linux February 16, 2010February 16, 2010

I’ve written shortly on this before. I like yum; I love apt-get; I prefer not to use them for MySQL installations. I consider a binary tarball to be the best MySQL installation format (source installations being a different case altogether).

#### Why?

I use yum and apt-get whenever I can and for almost all needs (sometimes preferring CPAN for Perl installations). But on a MySQL machine, I avoid doing so. The reason is either dependency hell or dependency mismatch.

Package managers are supposed to solve the dependency hell issue. But package managers will rarely have an up to date MySQL version.

I’ve had several experiences where a simple yum installation re-installed the MySQL version. I’ve had customers calling me up when, having installed something with yum, MySQL would not work anymore.

yum install package-which-depends-on-mysql-server will install MySQL server on your system if it hasn’t been installed with yum. Are you on CentOS 5.0? You’ll get MySQL 5.0.22. Oh, did you already have a RPM installation for MySQL 5.0.81? Sorry – it’s just been downgraded, plus it won’t work anymore since the error messages file has been changed since then.

Don’t press ‘Y‘ too soon!

Things are slightly better with apt-get. I’ve encountered less situations where mysql-server was on the dependency list. Many times it’s just the libmysqlclient package or the mysql-common one.

But wait! Did you install mysql-common? Bonus! You get the elusive /etc/mysql/my.cnf file created, and there goes your server configuration. Future spawns of the MySQL server / clients will read from the wrong configuration file, and will probably fail to load.

Not to mention neither will help you out with multiple instances installation.

#### My argument

A sys admin recently argued with me that it was wrong of me to have the entire machine set up with yum, but have MySQL installed with binary tarball. He argued that it broke the entire setup. I expressed my opinion: on a MySQL dedicated server, MySQL gets to be prioritized. It’s special. It is the reason for the existence of the machine. I would imagine that same would hold for Apache on an Apache dedicated machine, for Sendmail on a Sendmail dedicated machine, etc. As a DBA, I want to have best control of the MySQL installation; I want to be able to upgrade minor versions quickly: I often find newer versions to solve bugs I was concerned with; I want to be able to install multiple instances; I want to be able to downgrade without having to remove and uninstall the previous version.

I want to have control. World domination aside, that is.

- Twitter
- LinkedIn
- WhatsApp
- Email
- Facebook
- Print

###
26
Leave a Reply

26 Comment threads
0 Thread replies
0 Followers
Most reacted comment
Hottest comment thread
15 Comment authors
Recent comment authors

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe
Notify of
Guest
Norbert Tretkowski

MySQL only looks for /etc/mysql/my.cnf when /etc/my.cnf doesn’t exist, so installing mysql-common shouldn’t affect your manually installed MySQL server.

Guest
Randy ten Have

For Yum:
nano /etc/yum.conf
Add:
exclude=mysql* MySQL*

There is no exclude trick for apt-get as far as I know…

Author
shlomi

@Norbert,
This is correct, but my.cnf does not necessarily reside on /etc/. Especially if one has multiple installations.

@Randy,
Thanks!

Guest
sime

Fair point. But when the DBA wears multiple hats, like myself, yum/apt-get is best.

Guest
Onno Molenkamp

Even better is to create your own repository, with an up to date MySQL version in it. All packages that require mysql* will then happily use your own version, without breaking anything.

Author
shlomi

@sime.

It’s easier when you’re also the sys admin and are in full control. Even then there’s the issue of repositories not having an up-to-date MySQL version.

It’s more difficult when others are allowed to “yum install”.

Guest
coolghoul

@sime
I empathize. I’m a team of one handling multiple OS’s, app development, apache, mysql, and even some oracle dependent services. App dev alone is consuming.

I’m hopeful that cloud services will someday be the solution.

Guest
dheche

I always use binary version (installed via yum) for my production. It is easier for me to recreate the same environment for devel/test before push it to production. If i want playing a bit or want to mess up something, i always do it in devel env. After i check all is fine then i push it to production. I’m prohibit myself for installing compiler (gcc) in production environment. All changes (patch, compiling option, etc) are managed in rpm spec file, so me and my coworker is easier to track what change, what already implement by other. Did I mention… Read more »

Author
shlomi

@dheche
Just a quick note: installing a binary version does not require that you have gcc. It’s not a source distribution.

Guest
Daniel van Eeden

After a few security issues in the mysql-server packages in Ubuntu 6.06 LTS and almost nonexisted support from cannonical we switched to binary tarball installs. It works great. Switching to MySQL enterprise is also easier when you’re using tarballs.

Guest
Ronald Bradford

This is a common problem, and there is no ideal solution, however your comment of a MySQL specific machine, MySQL gets special treatment is a very valid point. However, so many organizations do not have a MySQL DBA, so the convenience of using one package installation process is a more practical solution for the System Administrator. These leads to a number of issues, the two most significant are: * Distro repositories are generally terribly outdated. You really need to either have your own repository or install the distro package from the MySQL downloads page. * Upgrades/Downgrades are tied into the… Read more »

Author
shlomi

@Ronald,
With regard to configuration file: this relates to apt-get, not to RPM installations, where I did not find this to be an issue.

Guest
Ryan Thiessen

I have the same preference, for the same reasons. Well put.

Guest
Tom Hanlon

Yum, uptodate, apt-get are sysadmin tools for managing dependencies and upgrades and clean rollout of new systems. The tend to handle glibc, vs python, vs ncurses very well, they tend to make a mess of MySQL. If a sysadmin told me that everything had to be handled by yum, then I would tell them to build me a mysql package with a socket /tmp/mysql.sock A datadir /somewhere/simple A basedir /somewhere/simple The sysadmin could look at the spec files of the standard rpms and perhaps come back with some suggestions, we negotiate and then we are done. When upgrades happen, I… Read more »

Guest
Peter Laursen

I never had any problems when installing with official MySQL generic RPM binaries using YaST. But I have not yet tried on any SuSE version after 11.0.

We have some issues ourself with shared library compliance with very recent distros based on gcc 4.2-4.3. Not sure about every detail yet but the most recent RHEL and CentOS in particular seem to have more such problems than Fedora and OpenSUSE (I will not comment on non-RPM distros).

Linux MySQL distros meeting in Brussels « JZ Talk Blogger

[…] 2008 MetaRegisterLog inRSS FeedComments RSSLinux MySQL distros meeting in BrusselsWhen I saw Shlomi’s post on why not to use apt-get or yum for MySQL, I thought immediately that his conclusions are quite reasonable. What you get from the Linux […]

Guest
Arjen Lentz

The issue is not the fact that it’s repos, but the “outdatedness” of the mysql versions in distros.

Try the MySQL 5.0 and MariaDB 5.1 repos at http://ourdelta.org/

Author
shlomi

Arjen,

Keep up the good work!

Guest
Brian Jones

I could be wrong about this, but I thought somewhere I read that it’s possible with apt-get to mark packages as installed, without them actually being installed, so the other packages which depend on them could be installed.

I could be wrong about this though.

Author
shlomi

Hi Brian,

apt-mark will let you mark packages as having been *automatically* installed, which means when you remove other packages that depend on said packages, they are automatically removed (as opposed to “I’ve manually installed thi package so do not remove it when you see no one using it”).

I’m not aware of marking non-existent packages as installed. But I’m not an expert on this.

Log Buffer #179: a Carnival of the Vanities for DBAs | The Pythian Blog

[…] Data Charmer, reports on the Linux MySQL distros meeting in Brussels. He says, “When I saw Shlomi’s post on why not to use apt-get or yum for MySQL, I thought immediately that his conclusions are quite reasonable. What you get from the Linux […]

Guest
Singer Wang

why “I consider a binary tarball to be the best MySQL installation format”.. If you on RHEL, why not get the MySQL RHEL RPMs?

Author
shlomi

@Singer,

I think I have it explained in the post.

Because:
1. They do not allow for multiple installations

2. yum will still remove such installations if it thinks it should

3. frankly, I don’t like it where RPMs have different conventions on different distros; not to mention different than deb packages.

/var/lib/mysql?
/var/run/mysql?

Poll: what (minor) versions of MySQL should be supported by an open source MySQL related project? | code.openark.org

[…] How about supporting 5.0.22 (released almost 4 years ago, with almost 70 revisions since)? Would you expect an open source project to support this MySQL version because, say, this is the default version in your yum repository? […]

Guide to MySQL installation files | code.openark.org

[…] To not yum or to not apt-get? […]

Installing MySQL from source/binary tarball as a Linux service | code.openark.org

[…] To not yum or to not apt-get? […]

wpDiscuz
Send to Email Address Your Name Your Email Address Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.