[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

eleventh-hour transition for mysql-using packages related to apache

Previously, a number of packages have had to continue to link against
libmysqlclient10 in spite of the availability of libmysqlclient12 libraries
from upstream's MySQL 4.0 release.  Some of these have been due to the lack
of a clear license exemption allowing libmyslqclient12 to be linked from
GPL-incompatible programs; others have been held back to avoid segfaults
caused by loading both libmysqlclient10 and libmysqlclient12 in the same
address space.

Over the past six months, the situation has changed significantly.  The
mysql maintainer, mysql upstream, and others have admirably worked through
the license issues to get a license exception that meets the needs of the
software that Debian distributes.  You can find the current version of this
license exception at [1].  At the same time, compatibility between the old
client libs and the current server (including the version that we will ship
with sarge) has waned, to the point that no libmysqlclient10 clients will
work with the default configuration of MySQL 4.1, and some won't work with
any MySQL 4.x server at all [2].

As a result, in spite of the timing wrt the release, I'm proposing a
transition to libmysqlclient12 for a number of packages for sarge.  The
packages listed below are those packages currently in sarge which either are
broken with MySQL 4.x, or have the possibility of conflicting with one of the
packages that do (mostly by being loaded by a webserver such as apache or
apache2, or being mysql bindings for a language that also has ODBC bindings).


It would also probably be a good idea to transition these packages at the
same time:


I have Cc:ed the maintainers of these packages.  If anyone knows of other
packages linked to libmysqlclient10 that will be affected by this
transition, please let us know.

While introducing versioned symbols into the mysqlclient libraries could
have a longer-term benefit in eliminating the kind of segfaults motivating
this all-at-once transition, in the present case there are other factors:

- since libmysqlclient10 didn't use symbol versioning in woody, users would
  still get segfaults from partial upgrades
- getting benefits from symbol versioning requires rebuilding all packages
  depending on the library *anyway*, so we might as well upgrade to the new
  version of the lib in the process.

I think it would be beneficial if libmysqlclient12 used symbol versioning
for sarge, but I don't think that we should wait for that to happen before
fixing the present issues.

The current plan for this transition is as follows:

- I will transition libmyodbc and php4 to libmysqlclient12 at the end of
  this weekend.  Other maintainers are encouraged to upload around the same
  time.  Maintainers who will not be around this week, and would like their
  packages to be NMUed, can email me privately.
- On Wednesday, Feb 2, I will file grave bugs on any remaining packages from
  the first list above that have not been relinked against libmysqlclient12,
  because they will now certainly cause segfaults in certain configurations.
  The packages in the second group will not be targetted, because NSS and
  PAM modules may cause some segfaults regardless of which library they link
  against, so the fact that they do not already have RC bugs against them
  means that this problem is probably quite rare.
- On Saturday, Feb 5, I will begin NMUing any packages from the first list
  that have still not been fixed.  Since there are only 17 source packages
  total, I expect to be done by the end of the weekend.

If you object to this plan, please speak up now.

Steve Langasek
postmodern programmer

[1] http://www.mysql.com/company/legal/licensing/foss-exception.html
[2] http://bugs.debian.org/274879

Attachment: signature.asc
Description: Digital signature

Reply to: