Excerpts from Robie Basak's message of 2016-09-05 18:59:39 +0100: > 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. >
I don't think we should gloss over this activity by MariaDB. They're completely aware of the fact that they're breaking with all norms by shipping a _forked_ API with the same soname as an established one. There's simply no reason for this to be entertained as anything other than aggressive anti-mysql activity. They could easily ship the original libmysqlclient API in a wrapper, and then build any new functionality into a mariadbclient so that users who link to the new one know they are dependent on MariaDB's new functionality. IMO, until they stop doing this, I don't think Debian should help them subvert MySQL by shipping this API under mysqlclient's soname.
