Posted by & filed under MySQL.

The packages of MySQL 5.5.19 are now available for Debian 6.0 “Squeeze” on both amd64 and i386 architectures. They fix some annoying issues that Dotdeb users kindly reported :

  • the mysql-common package, in its 5.5.19+ version, “breaks”  mysql-server-5.1 and mysql-client-5.1 (as APT means it – it won’t actually break your server into pieces). Freezing it will prevent any issue (the introduction of unknown configuration variables in their /etc/mysql/my.cnf, for example)
  • the MySQL client now uses the system’s readline library instead of the bundled editline wrapper
  • missing header files and libraries are now included in the appropriate packages

As usual, please read the full Changelog carefully before upgrading.

38 Responses to “MySQL 5.5.19”

  1. Guillaume Plessis

    @Rickard Andersson : the solution is to freeze the mysql-common package to its actual (compatible with MySQL 5.1) version. Then APT won’t to try to uninstall mysql-server anymore.

  2. joe

    i can’t use package mysql-server to make a mysql cluster ?
    there is no commands ndb_mgm/ndbd.

  3. Jordi

    Hi Guillaume,

    I don’t think Mysql 5.1 installation is working. I’m trying to install mysql-server-5.1 from a fresh Debian install using Dotdeb repos, and it installs nothing:

    # aptitude install mysql-server-5.1
    No packages will be installed, upgraded, or removed.
    0 packages upgraded, 0 newly installed, 0 to remove and 23 not upgraded.
    Need to get 0 B of archives. After unpacking 0 B will be used.

    And, about mysql-common solution, will it work with a fresh install? I mean, it seems to be only a mysql-common version and is for 5.5. If I don’t have a previous version I can’t install MySQL Server, right?


  4. Guillaume Plessis

    @Jordi : Here is the situation :

    – upgrading a MySQL 5.1 server => no problem
    – installing a MySQL 5.5 server => no problem
    – installing a MySQL 5.1 server from zero => dependency problem, because of the mysql-common package from MySQL 5.5, that

    Waiting for my fix, you can install (manually) mysql-common from MySQL 5.1 ( ) first, then install mysql-server-5.1 with a regular apt-get or equivalent. It should work.

  5. Jordi

    Ok, thanks for the info.
    I already figured out myself the manual installation solution (which I can confirm it works), but I discarted it because I use Puppet, and it just complicate things.

    Anyway, I’ll wait for your fix. Thanks again.

  6. Jockl


    Yesterday I did an upgrade from Lenny to Squeeze and I run into some problems. There is PHP5.3 and mysql-server 5.5 installed now (due to dotdeb-repository in sources.list).

    There are several databases on my vserver and some of them (not every!) are not accessible. I get this kind of error as shown on this page:

    I tried to solve the problem as described at this site although the password length already had been 16. Unfortunately it didn’t help. 🙁
    I am not able to use some of my databases (only via mysql shell) but phpmyadmin for example is not working as well.

    I also tried to enable/disable ‘old_passwords’ in my.cnf but without success….

    Any ideas are really much appreciated. 😉

    Thank you!

  7. Jockl

    I forgot to mention that I decided to keep the old configuration files during the upgrade from Lenny to Squeeze.

  8. Jockl

    It’s me again with good news. Don’t blame me but I forgot to “SET old_passwords = 0;”.

    Now everything seems to be running well… 🙂

  9. Guillaume Plessis

    @snf : thanks, I saw that. Is there any critical issue with MySQL 5.5.19 that would force me to package 5.5.20 as soon as possible? If not, you should expect a few days delay 🙂

  10. snf

    @Guillaume Plessis: well I saw an error fixed in InnoDB which is very simmilar to what I got just that friday. Changelog says that it should only be applicable for debug builds, but you never know. Anyway thanks for providing packages, debian experimental is still stuck at 5.5.17.


  11. snf

    @Guillaume Plessis: Just compared sources 5.5.19 vs 5.5.20, the Bug #13358468 seems to be related to my error, can you release .20 ASAP? Thanks in advance

  12. Joe Auty

    I’m noticing that the 5.5.19 mysql-server pkg requires libmysqlclient16. This is leading to more problems where stuff built against MySQL 5.5 is conflicting with the libmysqlclient16 pkg which seems to require being installed.


    Incorrect MySQL client library version! This gem was compiled for 5.5.18 but the client library is 5.1.58.

    Shouldn’t the last mysql-server depend on libmysqlclient18?

  13. Guillaume Plessis

    @Joe Auty : mysql-server 5.5.19 doesn’t depend on any libmysqlclient directly. But libdbi-perl from Debian does, on libmysqlclient16. The thrown message is just a warning, you can ignore it.

    Actually, there is a real annoying dependency problem with mysql-common, that prevents MySQL 5.1 to be installed from scratch. I’m working on it and it should be fixed with my MySQL 5.5.20 packages

  14. Joe Auty

    How can I remove libmysqlclient16 then without removing MySQL 5.5?

    # apt-get remove libmysqlclient16
    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    The following packages will be REMOVED:
    libdbd-mysql-perl libmysqlclient16 mysql-client-5.5 mysql-server mysql-server-5.5

  15. Joe Auty

    and the dotdeb MySQL 5.5 depends on libdbd-mysql-perl?

    # apt-get remove libdbd-mysql-perl
    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    The following packages will be REMOVED:
    libdbd-mysql-perl mysql-client-5.5 mysql-server mysql-server-5.5

    I’m confused… Why would the Debian made libdbd-mysql-perl depend on the Dotdeb MySQL packages even though when I do an “aptitude show libdbd-mysql-perl” I see:

    Depends: libc6 (>= 2.4), libmysqlclient16 (>= 5.1.21-1), perl (>= 5.10.1-13), perlapi-5.10.1, libdbi-perl (>= 1.610.90),

    What would have to happen in order to get rid of libmysqlclient16? Can I move/rename these libraries manually so that the libmysqlclient18 libraries are used instead?

    Sorry, just mostly confused.

  16. Guillaume Plessis

    libdbd-mysql-perl depends on libmysqlclient16, that is still provided by Dotdeb. If you absolutely want to remove libmysqlclient16 from your system, although there’s no problem having both libmysqlclient16 and libmysqlclient18 installed, feel free to rebuilt any MySQL-linked package (including libdbd-mysql-perl) against libmysqlclient18.

  17. Joe Auty

    All I want to do is work around these sorts of error messages while using Ruby gems:

    Incorrect MySQL client library version! This gem was compiled for 5.5.18 but the client library is 5.1.58.

    my thinking was that by getting rid of libmysqlclient16 the 5.1.58 client libraries would be unavailable to gems such as this, and the newer libraries would therefore be used.

    Any suggestions as to where I should focus my attention here in solving this problem, if not removing libmysqlclient16? I’m still unclear as to what is going on here with the dependencies, but I’m following up with what you said about how the two libraries can co-exist… Is there an environment variable that can be set to point to libmysqlclient18 or something?

  18. Joe Auty

    Okay, I think I understand what is going on with the dependencies…

    I’m wondering whether it is going to be easier to modify this Debian package, or just install a new version of the Perl/MySQL interface via CPAN… Hmm..

    It would be awesome if you guys would distribute a libdbd-mysql-perl with depends libmysqlclient18 (>= 5.5.whatever) 🙂

  19. Guillaume Plessis

    Just rebuild your mysql ruby extension ( libdbd-mysql-ruby ?) against libmsqylclient18.

    apt-get install libmysqlclient-dev (be sure it’s 5.5.x)
    apt-get source -b libdbd-mysql-ruby

  20. Guillaume Plessis

    Nope, doing this will force me to do it for every MySQL-linked package from Squeeze, leading for sure to conflicts, duplicate symbols and segfaults for users with custom configuration.

    Avoiding the mysql version warning does not worth it.

  21. Joe Auty

    Okay, I worked around this by updating some Ruby stuff via RVM. I guess this wasn’t a Dotdeb problem persay, but thanks for bearing with me, it was a learning process for me!

  22. John Tinker

    I got a “size mismatch” error, so canceled the installation. It also requested I run mysql_upgrade, which I did. Now it says I’m at 5.1.49. I want the date function on the partitioning, so am interested in 5.5. But I’m not sure it is going to go as planned. I read change logs and don’t see any problems there. My only concern really is with the installer, as I tend to trust completely to others in this regard. The installer is ready, right? What would the size mis-match have been about? Thanks for your efforts!

  23. Guillaume Plessis

    @John Tinker : just run “apt-get update” or equivalent, depending on your favorite package manager, to update the packages infos (including their size). Then you could install them without any issue.

  24. John Tinker

    Well, I actually do still have one problem. On the first machine I was working on, I was stabbing around a bit in the dark, and got a Synaptic process stuck somehow between mysql 5.1 and 5.5, and now on that first machine, I cannot shut the mysql server down because of a password issue. I can access the mysql server otherwise. The other two machines that I upgraded from 5.1 to 5.5 are working fine, no problems. But I wonder if there might be some advice for me regarding the password problem that I am having on the first machine?

  25. Guillaume Plessis

    @John Tinker : be sure that the debian-sys-maintainer user’s password is synchronized between /etc/mysql/debian.cnf and the content of your mysql.user table.

  26. John Tinker

    Guillaume Plessis, I had already done that, assuming that the value in /etc/mysql/debian.cnf had to be passed into SELECT PASSWORD(“”) in order to get the value to put into mysql.users. I had also used FLUSH PRIVILEDGES afterward.

    I can log into mysql as root at the command line. But if I try (as root)
    /etc/init.d/mysql stop
    it fails.

    If I try to turn off the mysql server via mysql-admin, it also fails.

  27. John Tinker

    @Guillaume Plessis. Thanks for the suggestions. Finally what worked was:
    mysqladmin -u root -p shutdown
    Once shutdown, then started again, everything began to behave normally.

    I think the take-home here is that (gui) mysql-admin couldn’t do it, but (command line) mysqladmin could.