[HEADS-UP] MySQL 5.5 coming soon to rawhide

[Michał Piotrowski]

Hi,

2010/12/22 Tom Lane <tgl at redhat.com>:
> Since MySQL AB^W^WSun^WOracle has now declared the mysql 5.5.x release
> series to be GA status, I'm planning to push it into rawhide shortly to
> replace the 5.1.x series.  Theoretically, this will go pretty smoothly.
>
> I'm aware of a couple of ABI-level issues:
>
> 1. libmysqlclient.so, which is linked into all manner of stuff, is
> supposed to be ABI-compatible with the previous releases.  However,
> I got tired of the amount of visible churn in exported-symbols-you're-
> not-supposed-to-use.  The new release will use a linker --version-script
> to hide everything except the documented API functions.  This might
> break any apps that are relying on non-API functions.  If so, I'm
> willing to consider on a case-by-case basis whether to add those symbols
> back to the ABI or fix the callers.


Hmm...

PHP Warning:  PHP Startup: Unable to load dynamic library
'/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so:
symbol client_errors, version libmysqlclient_16 not defined in file
libmysqlclient.so.16 with link time reference in Unknown on line 0

I guess I need to rebuild php. Apart of this for now works ok on my F14 :)

>
> 2. libmysqlclient_r.so is gone altogether; there's no need for it since
> the regular libmysqlclient.so library is supposed to be thread safe.
> AFAIK this will require rebuilding only the following packages:
>
> mysql++
> mysql-connector-c++
> nekovm
> qt-mysql
>
> For now I'll include a symlink libmysqlclient_r.so -> libmysqlclient.so,
> so that a simple rebuild with no source-code changes should be
> sufficient.  Eventually we'll probably want to fix the source code to
> not refer to libmysqlclient_r, but that might take awhile if upstreams
> are worried about portability.
>
>
> There are also some SQL-level incompatibilities called out here:
> http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html
> I'm not sure to what extent these may affect Fedora applications,
> but it seems like the easiest way to find out is to try them.
>
> Any objections?  Anything people think should be tested before pushing?
>
>                        regards, tom lane
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



-- 
Best regards,
Michal

Sent from my fscking awesome Black Hole Generator