[debian-mysql] Introducing default-mysql-* metapackages

[Ondřej Surý]

Robie,

there's exactly similar situation with libjpeg62. There's a default
libjpeg-dev package that depends on libjpeg62-turbo-dev

ondrej at yugen:~$ apt-file show libjpeg62-turbo
libjpeg62-turbo: /usr/lib/x86_64-linux-gnu/libjpeg.so.62
libjpeg62-turbo: /usr/lib/x86_64-linux-gnu/libjpeg.so.62.2.0
[...]
ondrej at yugen:~$ apt-file show libjpeg62-turbo-dev
libjpeg62-turbo-dev: /usr/lib/x86_64-linux-gnu/libjpeg.a
libjpeg62-turbo-dev: /usr/lib/x86_64-linux-gnu/libjpeg.so
[...]

I still think that the right solution would be to change the
libmysqlclient-dev to empty dependency package depending on
libmysqlclientXX-dev or libmariadbclientXX-dev and not to force all >=
300 packages to change Build-Depends in the debian/control.

> 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.

Here I disagree, exactly because what you write here:

> 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.

You'll end up with the exactly same situation. And I suspect nobody
really care about the client library used as long as it works. And it
would be substantially less work for other people to fix the few
packages that will break.

I did some big library transitions in the past and I think it is your
responsibility as a maintainer to test such a change.

So again I urge you to revert the decision to introduce yet another
change in the Build-Depends for >= 300 packages and just use the
libmysqlclient-dev package to be the "default".

Cheers,
-- 
Ondřej Surý <ondrej at sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba
všeho druhu

On Mon, Sep 5, 2016, at 19:59, Robie Basak wrote:
> 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