On Thursday 09 November 2017 14:26:01 Peter Rabbitson wrote: > On 11/09/2017 01:46 PM, Noel Butler wrote: > >On 09/11/2017 21:32, p...@cpan.org wrote: > > > >> > >>>What the complaints in this thread are focused on is what the *users* > >>>want. > >and the users want now, or will need in the near future, to build with > >latest, stable and recommended versions of MariaDB and MySQL. > > Which is a great thing to want. I want this too. This is not what the thread > is about. > > The problem stems from Pali mashing together 3(!)* independent concerns, and > presenting them as an "all or nothing" proposition: > 1. Inability to build against latest libmysql libs > 2. Several security fixes > 3. Entirely redefining how unicode is handled throughout the stack
As I already wrote, doing active development on code of DBD::mysql is hard or probably impossible if you want to have that old behavior. So fixing more parts of code or adding new features would lead to breaking that behavior or would be PITA for anybody who would need to guarantee that it would not be broken again in future. Moreover DBD::mysql itself (C part of code) misuse libmysql resp. libmariadb API which leads to segfaults (or silent memory corruption) when new mariadb is used. And this would be needed properly fixed if you want to support mariadb. So I guess it is better that compilation is failing. Users would not be surprised that driver really damaged data. And not just double encoded something to UTF-8 (due to misusing API) which has always 1:1 inverse operation and can be fixed. This part would not be simple to fix, there would be needed to of changes in whole driver, find all places where driver touch mariadb C structures... This is very good candidate which can break that old DBD::mysql behavior of handling blobs.
