Then users of MySQL would stay with DBD::mysql and they would not have fixed DBD driver. We were thinking about choosing DBD::mariadb name for our fork. But without dropping MySQL support, so also MySQL users could benefit from it.
On Monday 28 August 2017 18:08:20 Daniël van Eeden wrote: > What about splitting it in DBD::mysql and DBD::mariadb ? > > > On 28 August 2017 5:55:09 p.m. p...@cpan.org wrote: > > >Hello, 2 months passed since two security problems related to DBD::mysql > >were reported, namely CVE-2017-10789 and CVE-2017-10788. Looking at the > >DBD::mysql github project page and RT bugtracker, it can be seen that > >nothing has happened for 2 months. Some people are asking or waiting for > >reported problems to be fixed... Without an answer. > > > >A long discussion was started in April by a group of people who didn't > >like the improvements and didn't want to see the bugs fixed in > >DBD::mysql driver due to the fact that they probably had old and buggy > >legacy code which wouldn't work after DBD::mysql starts fixing bugs. > > > >From what happened it looks like that this group of people forced > >DBD::mysql maintainers to revert all DBD::mysql changes (with all bug > >fixes including security ones). And because nothing has happened for 2 > >months, that looks like fixing those bugs is not planned. > > > >This means just one thing: > > > > DBD::mysql is dead right now :-( > > > >There are no new commit for 2 months, no evidence of any activity. And > >it looks like this is what that group of people wanted. They haven't > >written anything, neither any comment about open security issues, nor > >any comment that they forced maintainers to revert a security related > >bug fix. Probably they don't have to fix their own code and they can use > >the last released version of DBD::mysql. Perfect for them, probably a > >catastrophe for all others which don't want to use probably-vulnerable > >code. > > > >But it also means that it isn't possible to compile the last DBD::mysql > >with the new MySQL 8 or new MariaDB versions. More linux distributions > >started to pack/bundle their own DBD::mysql patches just because they > >need to build DBD::mysql into their repositories with upgraded MariaDB. > > > >I need to say that such situation is not acceptable for *any* future or > >new development in Perl which uses either MySQL or MariaDB database. > > > >DBD::mysql has couple of bugs (some are security released) and fully > >non-working UTF-8/Unicode support. It means that any internationalized > >applications which use MySQL are hard to write in Perl. > > > >Because of the current situation we in the GoodData company are thinking > >about forking DBD::mysql. We use DBI not only with DBD::mysql, but also > >with DBD::Pg. The annoying bugs in DBD::mysql still require hacks and > >workarounds, while similar bugs were fixed in DBD::Pg years ago. Also, > >inability to use the new version of MySQL or MariaDB is a problem. Same > >for the open security issues. > > > >I would like to ask, whether somebody else is interested in DBD::mysql > >fork? Either as a user or as a developer? Maintaining a fork isn't a > >simple task, but with supporting users and contributing developers it > >should be easier. > > > >And specially, are MariaDB developers interested in fixing/improving > >DBD::mysql fork, so Perl could work better with MariaDB servers? At > >least it would be able to compile against the new MariaDB C-client? > >
