Log message:
Add BUILDLINK_LIBDIRS to mysql55-* too, to help out packages like
net/powerdns-mysql.

Log message:
Drop superfluous PKG_DESTDIR_SUPPORT, "user-destdir" is default these days.

Log message:
Changes 5.5.28:

The internal interface of the Thread Pool plugin has changed. Old versions of \ 
the plugin will work with current versions of the server, but versions of the \ 
server older than 5.5.28 will not work with current versions of the plugin.

Bugs Fixed

InnoDB: Certain information_schema tables originally introduced in MySQL 5.6 are \ 
now also available in MySQL 5.5 and MySQL 5.1: INNODB_BUFFER_PAGE, \ 
INNODB_BUFFER_PAGE_LRU, and INNODB_BUFFER_POOL_STATS.

InnoDB: When a SELECT ... FOR UPDATE, UPDATE, or other SQL statement scanned \ 
rows in an InnoDB table using a < or <= operator in a WHERE clause, the \ 
next row after the affected range could also be locked. This issue could cause a \ 
lock wait timeout for a row that was not expected to be locked. The issue \ 
occurred under various isolation levels, such as READ COMMITTED and REPEATABLE \ 
READ.

Partitioning: For tables using PARTITION BY HASH or PARTITION BY KEY, when the \ 
partition pruning mechanism encountered a multi-range list or inequality using a \ 
column from the partitioning key, it continued with the next partitioning column \ 
and tried to use it for pruning, even if the previous column could not be used. \ 
This caused partitions which possibly matched one or more of the previous \ 
partitioning columns to be pruned away, leaving partitions that matched only the \ 
last column of the partitioning key.

This issue was triggered when both of the following conditions were met:

The columns making up the table's partitioning key were used in the same order \ 
as in the partitioning key definition by a SELECT statement's WHERE clause as in \ 
the column definitions;

The WHERE condition used with the last column of the partitioning key was \ 
satisfied only by a single value, while the condition testing some previous \ 
column from the partitioning key was satisfied by a range of values.

An example of a statement creating a partitioned table and a query against this \ 
for which the issue described above occurred is shown here:

CREATE TABLE t1 (
  c1 INT,
  c2 INT,
  PRIMARY KEY(c2, c1)
) PARTITION BY KEY()  # Use primary key as partitioning key
  PARTITIONS 2;

SELECT * FROM t1 WHERE c2 = 2 AND c1 <> 2;
This issue is resolved by ensuring that partition pruning skips any remaining \ 
partitioning key columns once a partition key column that cannot be used in \ 
pruning is encountered.

Partitioning: The buffer for the row currently read from each partition used for \ 
sorted reads was allocated on open and freed only when the partitioning handler \ 
was closed or destroyed. For SELECT statements on tables with many partitions \ 
and large rows, this could cause the server to use excessive amounts of memory.

This issue has been addressed by allocating buffers for reads from partitioned \ 
tables only when they are needed and freeing them immediately once they are no \ 
longer needed. As part of this fix, memory is now allocated for reading from \ 
rows only in partitions that have not been pruned (see Section 18.4, \ 
“Partition Pruning”).

Replication: On 64-bit Windows platforms, values greater than 4G for the \ 
max_binlog_cache_size and max_binlog_stmt_cache_size system variables were \ 
truncated to 4G. This caused LOAD DATA INFILE to fail when trying to load a file \ 
larger than 4G in size, even when max_binlog_cache_size was set to a value \ 
greater than this.

Replication: In master-master replication with --log-slave-updates enabled, \ 
setting a user variable and then performing inserts using this variable caused \ 
the Exec_master_log_position column in the output of SHOW SLAVE STATUS not to be \ 
updated.

The RPM spec file now also runs the test suite on the new binaries, before \ 
packaging them.

The libmysqlclient_r client library exported symbols from yaSSL that conflict \ 
with OpenSSL. If a program linked against that library and libcurl, it could \ 
crash with a segmentation fault.

The argument for LIMIT must be an integer, but if the argument was given by a \ 
placeholder in a prepared statement, the server did not reject noninteger values \ 
such as '5'.

The Thread Pool plugin did not respect the wait_timeout timeout for client sessions.

CHECK TABLE and REPAIR TABLE could crash if a key definition differed in the \ 
.frm and .MYI files of a MyISAM table. Now the server produces an error.

A query for a FEDERATED table could return incorrect results when the underlying \ 
table had a compound index on two columns and the query included an AND \ 
condition on the columns.

mysqlhotcopy failed for databases containing views.

The argument to the --ssl-key option was not verified to exist and be a valid \ 
key. The resulting connection used SSL, but the key was not used.

Adding a LIMIT clause to a query containing GROUP BY and ORDER BY could cause \ 
the optimizer to choose an incorrect index for processing the query, and return \ 
more rows than required.

mysqlbinlog did not accept input on the standard input when the standard input \ 
was a pipe.

Log message:
Changes 5.5.27:
Important Change: The YEAR(2) data type is now deprecated because it is \ 
problematic. Support for YEAR(2) will be removed in a future release of MySQL. \ 
For more information, see Section 11.3.4, “YEAR(2) Limitations and \ 
Migrating to YEAR(4)”.

Log message:
Changes 5.5.25a:
* A regression bug in the optimizer could cause excessive disk usage for UPDATE \ 
statements.

Log message:
Changes 5.5.25:
* The --safe-mode server option now is deprecated and will be removed in MySQL
  5.6.
* Performance: InnoDB: Improved the algorithm related to adaptive flushing.
  This fix increases the rate of flushing in cases where compression is used
  and the data set is larger than the buffer pool, leading to eviction.
* InnoDB: In a transaction using the REPEATABLE READ isolation level, an UPDATE
  or DELETE statement for an InnoDB table could sometimes overlook rows
  recently committed by other transactions. As explained in Section 14.3.9.2,
  “Consistent Nonlocking Reads”, DML statements within a REPEATABLE READ
  transaction apply to rows committed by other transactions, even if a query
  could not see those rows.
* InnoDB: The Innodb_buffer_pool_pages_flushed status variable was incorrectly
  set to twice the value it should be. Its value should never exceed the value
  of Innodb_pages_written.
* InnoDB: The error handling and message was improved for attempting to create
  a foreign key with a column referencing itself. The message suggested
  a potential problem with the data dictionary, when no such problem existed.
* InnoDB: The CHECK TABLE statement could fail for a large InnoDB table due to
  a timeout value of 2 hours. For typical storage devices, the issue could
  occur for tables that exceeded approximately 200 or 350 GB, depending on I/O
  speed. The fix relaxes the locking performed on the table being checked,
  which makes the timeout less likely. It also makes InnoDB recognize the
  syntax CHECK TABLE QUICK, which avoids the possibility of the timeout
  entirely.
* Replication: It was theoretically possible for concurrent execution of more
  than one instance of SHOW BINLOG EVENTS to crash the MySQL Server.
* Replication: Statements using AUTO_INCREMENT, LAST_INSERT_ID(), RAND(), or
  user variables could be applied in the wrong context on the slave when using
  statement-based replication and replication filtering server options (see
  Section 16.2.3, “How Servers Evaluate Replication Filtering Rules”).
* Replication: An INSERT into a table that has a composite primary key that
  includes an AUTO_INCREMENT column that is not the first column of this
  composite key is not safe for statement-based binary logging or replication.
  Such statements are now marked as unsafe and fail with an error when using
  the STATEMENT binary logging format. For more information, see Section
  16.1.2.3, “Determination of Safe and Unsafe Statements in Binary \ 
Logging”, as
  well as Section 16.4.1.1, “Replication and AUTO_INCREMENT”.

Log message:
Update mysql55-{client,server} to 5.55.24.

Changes (http://dev.mysql.com/doc/refman/5.5/en/news-5-5-24.html):

Functionality Added or Changed

    * Important Change: Replication: INSERT ON DUPLICATE KEY UPDATE is now
      marked as unsafe for statement-based replication if the target table has
      more than one primary or unique key. For more information, see Section
      16.1.2.3, "Determination of Safe and Unsafe Statements in Binary
      Logging".

Bugs Fixed

    * Security Fix: Bug #64884 was fixed.

    * InnoDB: Replication: When binary log statements were replayed on the
      slave, the Com_insert, Com_update, and Com_delete counters were
      incremented by BEGIN statements initiating transactions affecting InnoDB
      tables but not by COMMIT statements ending such transactions. This
      affected these statements whether they were replicated or they were run
      using mysqlbinlog. (Bug #12662190)

    * If the --bind-address option was given a host name value and the host
      name resolved to more than one IP address, the server failed to
      start. For example, with --bind-address=localhost, if localhost resolved
      to both 127.0.0.1 and ::1, startup failed. Now the server prefers the
      IPv4 address in such cases. (Bug #61713, Bug #12762885)

    * mysql_store_result() and mysql_use_result() are not for use with
      prepared statements and are not intended to be called following
      mysql_stmt_execute(), but failed to return an error when invoked that
      way in libmysqld. (Bug #62136, Bug #13738989)

      References: See also Bug #47485.

    * On Windows, mysqlslap crashed for attempts to connect using shared
      memory. (Bug #31173, Bug #11747181, Bug #59107, Bug #11766072)

Log message:
Changes 5.5.23:
Bugs Fixed
* Security Fix: Bug 59533 was fixed.
* Performance: Partitioning: InnoDB Storage Engine: The statistics used by the
  optimizer for queries against partitioned InnoDB tables were based only on the
  first partition of each such table, leading to use of the wrong execution
  plan.
* References: This bug was introduced by Bug 11756867.
* Performance: InnoDB Storage Engine: Improved the performance of the DROP TABLE
  statement for InnoDB tables, especially on systems with a large buffer pool.
  The fix speeds up the processing for freeing entries in the adaptive hash
  index.
* InnoDB Storage Engine: Deleting a huge amount of data from InnoDB tables
  within a short time could cause the purge operation that flushes data from the
  buffer pool to stall. If this issue occurs, restart the server to work around
  it. This issue is only likely to occur on 32-bit platforms.
* InnoDB Storage Engine: If the server crashed during a TRUNCATE TABLE or CREATE
  INDEX statement for an InnoDB table, or a DROP DATABASE statement for
  a database containing InnoDB tables, an index could be corrupted, causing an
  error message when accessing the table after restart:
  InnoDB: Error: trying to load index index_name for table table_name
  InnoDB: but the index tree has been freed!
  In MySQL 5.1, this fix applies to the InnoDB Plugin, but not the built-in
  InnoDB storage engine.
* InnoDB Storage Engine: When data was removed from an InnoDB table, newly
  inserted data might not reuse the freed disk blocks, leading to an unexpected
  size increase for the system tablespace or .ibd file (depending on the
  setting of innodb_file_per_table. The OPTIMIZE TABLE could compact a .ibd file
  in some cases but not others. The freed disk blocks would eventually be
  reused as additional data was inserted.
More...

Log message:
Changes 5.5.22:
* InnoDB Storage Engine: A deprecation warning is now issued when
  --ignore-builtin-innodb is used.
* yaSSL was upgraded from version 1.7.2 to 2.2.0.
* Security Fix: Bug 13510739 and Bug 63775 were fixed.
* Important Change: InnoDB Storage Engine: When a row grew in size due to an
  UPDATE operation, other (non-updated) columns could be moved to off-page
  storage so that information about the row still fit within the constraints of
  the InnoDB page size. The pointer to the new allocated off-page data was not
  set up until the pages were allocated and written, potentially leading to
  lost data if the system crashed while the column was being moved out of the
  page. The problem was more common with tables using ROW_FORMAT=DYNAMIC or
  ROW_FORMAT=COMPRESSED along with the Barracuda file format, particularly with
  the innodb_file_per_table setting enabled, because page allocation operations
  are more common as the .ibd tablespace files are extended. Still, the problem
  could occur with any combination of InnoDB version, file format, and row
  format.
* InnoDB Storage Engine: An erroneous assertion could occur, in debug builds
  only, when creating an index on a column containing zero-length values (that
  is, '').
* InnoDB Storage Engine: A DDL operation such as ALTER TABLE ... ADD COLUMN
  could stall, eventually timing out with an Error 1005: Can't create table
  message referring to fil_rename_tablespace.
* InnoDB Storage Engine: A DDL operation for an InnoDB table could cause a busy
  MySQL server to halt with an assertion error:
More...

Log message:
Changes 5.5.21:
* A new CMake option, MYSQL_PROJECT_NAME, can be set on Windows or Mac OS X to
  be used in the project name.
Bugs Fixed
* Performance: InnoDB Storage Engine: Memory allocation for InnoDB tables was
  reorganized to reduce the memory overhead for large numbers of tables or
  partitions, avoiding situations where the “resident set size” could grow
  regardless of FLUSH TABLES statements. The problem was most evident for tables
  with large row size.
* Incompatible Change: An earlier change (in MySQL 5.1.62 and 5.5.21) was found
  to modify date-handling behavior in General Availability-status series (MySQL
  5.1 and 5.5). This change has been reverted.
* The change was that several functions became more strict when passed a DATE()
  function value as their argument, thus they rejected incomplete dates with
  a day part of zero. These functions were affected: CONVERT_TZ(), DATE_ADD(),
  DATE_SUB(), DAYOFYEAR(), LAST_DAY(), TIMESTAMPDIFF(), TO_DAYS(), TO_SECONDS(),
  WEEK(), WEEKDAY(), WEEKOFYEAR(), YEARWEEK(). The previous behavior has been
  restored.
* InnoDB Storage Engine: A Valgrind error was fixed in the function
  os_aio_init().
* InnoDB Storage Engine: The server could crash when creating an InnoDB
  temporary table under Linux, if the $TMPDIR setting points to a tmpfs
  filesystem and innodb_use_native_aio is enabled, as it is by default in MySQL
  5.5.4 and higher.
* InnoDB Storage Engine: References to C preprocessor symbols and macros
  HAVE_purify, UNIV_INIT_MEM_TO_ZERO, and UNIV_SET_MEM_TO_ZERO were removed
  from the InnoDB source code. They were only used in debug builds instrumented
  for Valgrind. They are replaced by calls to the UNIV_MEM_INVALID() macro.