You cannot go further without either breaking existing code. You *can* fix the code in a fork. This gives people the of switching to the fork when *they* want to. Or don’t switch.
Seems to me forking is the only way forward. Just my 2c worth, having been exposed to these shenanigans of point #1 extensively at former $work. Liz > On 10 Nov 2017, at 15:03, p...@cpan.org wrote: > > On Friday 10 November 2017 10:09:59 demerphq wrote: >> Pali is there a concise summary of what we are arguing about here? > > Short summary: > > 1. There are applications which misuse perl and DBD::mysql internals to > pass blob or utf-8 text data from perl to MySQL database. We were not > aware of them for a longer testing period of time as nobody > complained until version 4.042 of DBD::mysql was released. There were > trial releases, blog posts, asking testers for test, etc... > > 2. Unicode support in DBD::mysql is broken and cause data corruption. > There are lot of reported bugs about it, e.g.: > https://rt.cpan.org/Public/Bug/Display.html?id=25590 > https://rt.cpan.org/Public/Bug/Display.html?id=53130 > https://rt.cpan.org/Public/Bug/Display.html?id=60987 > https://rt.cpan.org/Public/Bug/Display.html?id=87428 > https://rt.cpan.org/Public/Bug/Display.html?id=119079 > https://rt.cpan.org/Public/Bug/Display.html?id=120141 > All those problems were fixed, but breaking applications which misuse > internals. Basically Unicode support is opposite of the above. > All fixes from 4.042 were reverted and version 4.043 was released. > > 3. DBD::mysql itself misuse libmysqlclient internals for a long time and > now when MariaDB changed something, it cannot be used with DBD::mysql > anymore. > > 4. Due to how Oracle (not) reacted and (not) fixed problems related to > SSL, DBD::mysql has a security problems when SSL encryption is used. > There are also other crashing problems in DBD::mysql. > > 5. Misusing internals of 3rd applications which use DBD::mysql is a > problem because basically any change of low level parts in DBD::mysql > can lead to breakage of those 3rd applications. And because nobody > was able to detect it would break something there is a really big > chance that bigger changes in DBD::mysql break something again. > Fixing 3. is expected to be big change.
