Salut,
On met à jour le serveur MySQL pour suivre les mise à jour de sécurité de Debian. Normalement, ça casse rien. Mais ici, ça risque de casser des choses.
Explications :
Habituellement, quand une faille est corrigé dans une version, Debian patch la version qu’il « utilise » actuellement pour profiter des corrections de failles, sans faire de changement de fonctionnalité. Ainsi, on a aucune faille, mais on ne s’est pas introduit des bugs pour des incompatibilités.
Ici, Oracle a décidé de corriger des failles sans dire lesquelles. Deux choix alors pour Debian : ne pas corriger les failles, ou bien mettre en place la « nouvelle » version de Oracle sans pouvoir valider qu’il n’y aurais pas de problème.
Debian a fait le choix de corriger les failles. Compte tenu de leur gravité, je (Fufroma) considére qu’ils ont eu raison. Reste que certains d’entre vous risque d’avoir des bugs de MySQL à partir de maintenant.
Voici la liste des problèmes qui peuvent être présent suite à la mise à jour :
mysql-5.1 (5.1.61-1) stable-security; urgency=high
Due to the non-disclosure of security patch information from Oracle,
we are forced to ship this upstream version update of MySQL 5.1 into
all releases that carry MySQL 5.1. There are several known incompatible
changes, which are listed below, taken from dev.mysql.com’s changelogs,
available here: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-x.html
5.1.51:
Incompatible Change: Previously, if you flushed the logs using FLUSH
LOGS or mysqladmin flush-logs and mysqld was writing the error log to
a file (for example, if it was started with the –log-error option),
it renamed the current log file with the suffix -old, then created a
new empty log file. This had the problem that a second log-flushing
operation thus caused the original error log file to be lost unless
you saved it under a different name. For example, you could use the
following commands to save the file:
.
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
.
To avoid the preceding file-loss problem, renaming no longer
occurs. The server merely closes and reopens the log file. To rename
the file, you can do so manually before flushing. Then flushing the
logs reopens a new file with the original file name. For example, you
can rename the file and create a new one using the following commands:
.
shell> mv host_name.err host_name.err-old
shell> mysqladmin flush-logs
shell> mv host_name.err-old backup-directory
.
(Bug #29751)
.
References: See also Bug #56821.
5.1.55:
Incompatible Change: When auto_increment_increment is greater than
one, values generated by a bulk insert that reaches the maximum
column value could wrap around rather producing an overflow error.
.
As a consequence of the fix, it is no longer possible for an
auto-generated value to be equal to the maximum BIGINT UNSIGNED
value. It is still possible to store that value manually, if the
column can accept it. (Bug #39828, Bug #11749800)
5.1.59:
Incompatible Change: Handling of a date-related assertion was
modified.
.
However, a consequence of this change is that several functions
become more strict when passed a DATE() function value as their
argument and reject incomplete dates with a day part of zero. These
functions are affected: CONVERT_TZ(), DATE_ADD(), DATE_SUB(),
DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(),
WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). Because this changes
date-handling behavior in General Availability-status series (MySQL
5.1 and 5.5), it was reverted in 5.1.62 and 5.5.21. The change is
retained in MySQL 5.6.
.
References: See also Bug #13458237.
— Clint Byrum Thu, 01 Mar 2012 23:25:34 -0800
