Juste sur une machine qui craint pas trop, pour voir ce que ça donne : les incompatibilités en question ne me concernent pas, mais même si je pense que ça sera bon pour moi mon côté méfiant a quand même tendance à s’agiter face à ce genre de conneries. 
Pour ceux qui hésitent, voici la liste complète :
[quote]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: 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 clint@ubuntu.com Thu, 01 Mar 2012 23:25:34 -0800[/quote]
