Hi Ondřej, On Mon, Sep 05, 2016 at 08:57:57AM +0200, Ondřej Surý wrote: > could you elaborate a bit more why you are forcing all Build-RDeps to > change B-D to default-libmysqlclient-dev instead of just changing the > semantics of libmysqlclient-dev?
MySQL ships the soname libmysqlclient.so.20 (in experimental currently, 18 in unstable and testing) and continues to be maintained in Debian. So the expected package names to get libmysqlclient.so.20 are libmysqlclient20 and libmysqlclient-dev, according to Debian policy sections 8.1 and 8.4. libmysqlclient-dev should result in a link against MySQL's libmysqlclient.so. MariaDB upstream do also ship libmysqlclient.so.18 (forked from an older MySQL), but clearly it would be insane to ship this in Debian in the same way because of the soname conflict. I understand why MariaDB upstream have done it this way, but their expected use case is that a user would pick MariaDB and drop everything MySQL. Since we're not doing that in Debian, this cannot work. So instaed, it makes sense for us to ship separate sonames, so we are patching MariaDB to build libmariadbclient.so.18 instead. Having a package build depend on libmysqlclient-dev, link with "-lmysqlclient" and then up with with a binary dependency on libmariadbclient.so.18 would be wrong, IMHO. That's why I want to leave libmysqlclient-dev alone, and why we're moving this necessary insanity to libmariadbclient-dev-compat instead. Then it's clear. We then have the need for a "default" package, libmysqlclient-dev is already taken, and default-libmysqlclient-dev follows the same pattern as the others. It is perhaps a little confusing because as long as the default is MariaDB, packages using it will end up with a binary dependency on libmariadbclient.so.18 from libmariadbclient-dev instead, but I think that all the other options we've considered are worse. At least this way the insanity is limited to the -compat package, and by extension the default- package, but everything else will appear as normal. Robie
