Re: [debian-mysql] Introducing default-mysql-* metapackages
Robie, I have no idea why are you talking about -compat packages and mariadb shipping libmysqlclient. The initial email stated: > Packages built against default-mysqlclient-dev and link using > "-lmysqlclient" will end up with a shared library dependency on either > libmysqlclient.so.X or libmariadbclient.so.X depending on the default > defined by the release team at build time. These will be provided by > the libmysqlclient18 (soon to be libmysqlclient20) and > libmariadbclient18 packages, which will be co-installable. Packages > which require particular functionality available from only one of the > forks may Build-Depend directly on libmysqlclient-dev or > libmariadbclient-dev and then link using "-lmysqlclient" or > "-lmariadbclient" respectively. Again, please get in touch if this > applies to you. But I don't care that much to continue this discussion as you clearly seem to have strong opinion about that. You (as the pkg-mysql team) are the one who will be clearing the mess in the release, so it's definitely up to you how you want to handle this. I expressed my opinion and I will not pursue this discussion further. Cheers, -- Ondřej Surý 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 Wed, Sep 7, 2016, at 12:09, Robie Basak wrote: > On Tue, Sep 06, 2016 at 09:00:37AM +0200, Ondřej Surý wrote: > > 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". > > Sorry, I disagree. The situation with MariaDB needing to ship > libmysqlclient.so is broken. I'd prefer to restrict this insanity to the > -compat package only. > > This way: > > * The insanity only slips further to the defaults- package but no > further. > > * Packages that don't have to be involved don't get dragged in. > > * The "shoulds" in package naming in Debian policy (8.1/8.4) are met. > > Robie >
Re: [debian-mysql] Introducing default-mysql-* metapackages
On Tue, Sep 06, 2016 at 09:00:37AM +0200, Ondřej Surý wrote: > 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". Sorry, I disagree. The situation with MariaDB needing to ship libmysqlclient.so is broken. I'd prefer to restrict this insanity to the -compat package only. This way: * The insanity only slips further to the defaults- package but no further. * Packages that don't have to be involved don't get dragged in. * The "shoulds" in package naming in Debian policy (8.1/8.4) are met. Robie
Re: [debian-mysql] Introducing default-mysql-* metapackages
Robie, there's exactly similar situation with libjpeg62. There's a default libjpeg-dev package that depends on libjpeg62-turbo-dev ondrej@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@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ý 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
Re: [debian-mysql] Introducing default-mysql-* metapackages
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.
Re: [debian-mysql] Introducing default-mysql-* metapackages
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
Re: Introducing default-mysql-* metapackages
Hello! 2016-09-05 9:57 GMT+03:00 Ondřej Surý : > 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? > > I understand the default-mysql-client and default-mysql-server, but I > don't understand the change from libmysqlclient-dev to > default-libmysqlclient-dev. > > We have a couple of similar cases that doesn't require that much work > (f.e. libjpeg-dev) and renaming the original libmysqlclient-dev to > libmysqlclient-oracle-dev and adding Provides: libmysqlclient-dev to > libmariadbclient-dev would achieve the same thing and require a > substantially less work on the other people side. Thanks for the suggestion. This method was not discussed earlier when the pkg-mysql-maint team designed the new mysql-defaults metapackages. I would be fine by doing what you suggest. What does Robie and others who are more vested in maintaining Oracle packages think about this? - Otto
Re: Introducing default-mysql-* metapackages
Folks, 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? I understand the default-mysql-client and default-mysql-server, but I don't understand the change from libmysqlclient-dev to default-libmysqlclient-dev. We have a couple of similar cases that doesn't require that much work (f.e. libjpeg-dev) and renaming the original libmysqlclient-dev to libmysqlclient-oracle-dev and adding Provides: libmysqlclient-dev to libmariadbclient-dev would achieve the same thing and require a substantially less work on the other people side. Cheers, -- Ondřej Surý 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 Sun, Sep 4, 2016, at 09:14, Otto Kekäläinen wrote: > Hello maintainers of packages that depend in MySQL/MariaDB! > > TL;DR; > > Please update packages that depend on MySQL or MariaDB as follows: > > BEFORE: Build-Depends: libmysqlclient-dev > AFTER: Build-Depends: default-libmysqlclient-dev > > BEFORE: Depends: mysql-server | virtual-mysql-server > OR Depends: mariadb-server | virtual-mysql-server > AFTER: Depends: default-mysql-server | virtual-mysql-server > > BEFORE: Depends: mysql-client | virtual-mysql-client > OR Depends: mariadb-client | virtual-mariadb-client > AFTER: Depends: default-mysql-client | virtual-mysql-client > > > Details follow: > > The release team decided earlier in the spring that MariaDB should be > made the default MySQL variant in Debian. The release team also wished > to have a facility that allows easy switching of the default. > > Therefore we have introduced the following metapackages > from the mysql-defaults source package: > - default-mysql-server > - default-mysql-server-core > - default-mysql-client > - default-mysql-client-core > - default-libmysqlclient-dev > > All maintainers of packages that currently depend directly on > mysql-server, mariadb-server, or any of the other packages in these > series, shall update the dependencies in their packages to point to > default-mysql-* instead. > > Installing the metapackage default-mysql-server will pull in > mariadb-server-10.0. Users who had mysql-server-5.6 will have it > removed and replaced by the MariaDB equivalent on upgrade. Note that > once you have switched to MariaDB, it might not possible to convert > your in-place database files back to MySQL automatically, since Oracle > does not maintain tools to convert possible MariaDB features present > in the binary format. Please back up your data first if you wish to > switch or experiment. Manual dump/import is the most reliable way to > import data from one installation to another. > > A virtual package scheme virtual-mysql-* already exists since 2013, > and will continue to exist. All MySQL variants in Debian (and outside > in 3rd party repositories too) have Provides for these virtual-mysql-* > packages. Maintainers can must use "Depends: default-mysql-server | > virtual-mysql-server" if their package can be satisfied by any MySQL > variant (Oracle, MariaDB, Percona, mysql-wsrep). > > The first dependency should be default-mysql-*, which is a > metapackage, that in turn depends on exactly one option, which for now > is MariaDB. > > If a maintainer knows that his/her package only works with one > variant, then the package can depend directly on that package and not > use the default-mysql-* (matches one) or virtual-mysql-* (matches any) > schemes. Please get in touch if this applies to you. At the moment > there should be no such packages, but in the future cases like this > can arise when MySQL and MariaDB develop diverging feature sets. > > Packages built against default-mysqlclient-dev and link using > "-lmysqlclient" will end up with a shared library dependency on either > libmysqlclient.so.X or libmariadbclient.so.X depending on the default > defined by the release team at build time. These will be provided by > the libmysqlclient18 (soon to be libmysqlclient20) and > libmariadbclient18 packages, which will be co-installable. Packages > which require particular functionality available from only one of the > forks may Build-Depend directly on libmysqlclient-dev or > libmariadbclient-dev and then link using "-lmysqlclient" or > "-lmariadbclient" respectively. Again, please get in touch if this > applies to you. > > Users that want to rebuild packages against a different variant of > lib*client-dev for experimenting and testing locally should prefer > using a locally modified default-libmysqlclient-dev over modifying > each client application source package individually. > > The default-mysql-* metapackages have been available in experimental > since July, and since also in unstable and testing, and we are > confident there are no regressio
Re: [debian-mysql] Introducing default-mysql-* metapackages
Hi, On Tue, Aug 16, 2016 at 11:36:15AM +0300, Otto Kekäläinen wrote: > Yes, this scheme is very flexible and in cases like > > mysql-connector-c++ the package can depend explicitly on the MySQL > > package and not the default package. OK. > > Or we keep a working version with MariaDB, but then again there's other > > packages like mysql-workbench also wanting 1.1.7 (and thus MySQL 5.7)... > > I think mysql-workbench works just fine with MariaDB, it only > complains about the version string not being what it assumes as it > thinks 10.0 < 5.x and it requires 5.x or later. Somebody should patch > mysql-workbench to do proper version string comparison. Sure, but TTBOMK it wants Connector/C >= 1.1.7 which then in turn needs libmysqlclient-dev 5.7. That was the point. I also think it should be able to _connect_ to a MariaDB then... Regards, Rene
Re: [debian-mysql] Introducing default-mysql-* metapackages
Hello! 2016-08-16 7:44 GMT+03:00 Rene Engelhard : > On Sun, Jul 10, 2016 at 05:22:22PM +0300, Otto Kekäläinen wrote: >> Hello maintainers of packages that depend in MySQL/MariaDB! > > Not everyone is required to read -devel. Mailing them where they read > it (and be it Cc'ing them) would be better. > > I am subscribed to -devel but still missed this mail (though I knew there > was something ongoing) That is why we'll send a mail about this to debian-devel-announce soon to get more visibility. >> BEFORE: Build-Depends: libmysqlclient-dev >> AFTER: Build-Depends: default-libmysqlclient-dev >> >> BEFORE: Depends: mysql-server | virtual-mysql-server OR Depends: >> mariadb-server | virtual-mysql-server >> AFTER: Depends: default-mysql-server | virtual-mysql-server >> >> BEFORE: Depends: mysql-client | virtual-mysql-client OR Depends: >> mariadb-client | virtual-mariadb-client >> AFTER: Depends: default-mysql-client | default-mysql-client > > ITYM virtual-mysql-client :) Yes, sorry for the typo. >> If a maintainer knows that his/her package only works with one >> variant, then the package can depend directly on that package and not >> use the default-mysql-* (matches one) or virtual-mysql-* (matches any) >> schemes. Please get in touch if this applies to you. At the moment >> there should be no such packages, but in the future cases like this >> can arise when MySQL and MariaDB develop diverging feature sets. > > Well, I know of packages needing MySQL 5.7 and/or failing to build against > MariaDB for other reasons. e.g. mysql-connector-c++. Upstream is Oracle, > so they obviously won't care about MariaDB.. Yes, this scheme is very flexible and in cases like mysql-connector-c++ the package can depend explicitly on the MySQL package and not the default package. The same applies also for some packages that use features available in MariaDB but not available in MySQL. >> Packages built against default-mysqlclient-dev and link using >> "-lmysqlclient" will end up with a shared library dependency on either >> libmysqlclient.so.X or libmariadbclient.so.X depending on the default >> defined by the release team at build time. These will be provided by >> the libmysqlclient18 (soon to be libmysqlclient20) and >> libmariadbclient18 packages, which will be co-installable. Packages >> which require particular functionality available from only one of the >> forks may Build-Depend directly on libmysqlclient-dev or >> libmariadbclient-dev and then link using "-lmysqlclient" or >> "-lmariadbclient" respectively. Again, please get in touch if this >> applies to you. > > See above. > > So this one could still use libmysqlclient-dev? Yes > Or we keep a working version with MariaDB, but then again there's other > packages like mysql-workbench also wanting 1.1.7 (and thus MySQL 5.7)... I think mysql-workbench works just fine with MariaDB, it only complains about the version string not being what it assumes as it thinks 10.0 < 5.x and it requires 5.x or later. Somebody should patch mysql-workbench to do proper version string comparison. >> The default-mysql-* metapackages will be uploaded to Experimental soon >> and to Unstable once we are confident there are no regressions. Once >> they are available in Unstable, we will announce this on > > I have seen those accepted in unstable this morning so.. :) Yes, it was uploaded 12 hours ago. I didn't have time to announce it just yet. Stay tuned :)
Re: Introducing default-mysql-* metapackages
Hi, On Sun, Jul 10, 2016 at 05:22:22PM +0300, Otto Kekäläinen wrote: > Hello maintainers of packages that depend in MySQL/MariaDB! Not everyone is required to read -devel. Mailing them where they read it (and be it Cc'ing them) would be better. I am subscribed to -devel but still missed this mail (though I knew there was something ongoing) > BEFORE: Build-Depends: libmysqlclient-dev > AFTER: Build-Depends: default-libmysqlclient-dev > > BEFORE: Depends: mysql-server | virtual-mysql-server OR Depends: > mariadb-server | virtual-mysql-server > AFTER: Depends: default-mysql-server | virtual-mysql-server > > BEFORE: Depends: mysql-client | virtual-mysql-client OR Depends: > mariadb-client | virtual-mariadb-client > AFTER: Depends: default-mysql-client | default-mysql-client ITYM virtual-mysql-client :) > If a maintainer knows that his/her package only works with one > variant, then the package can depend directly on that package and not > use the default-mysql-* (matches one) or virtual-mysql-* (matches any) > schemes. Please get in touch if this applies to you. At the moment > there should be no such packages, but in the future cases like this > can arise when MySQL and MariaDB develop diverging feature sets. Well, I know of packages needing MySQL 5.7 and/or failing to build against MariaDB for other reasons. e.g. mysql-connector-c++. Upstream is Oracle, so they obviously won't care about MariaDB.. > Packages built against default-mysqlclient-dev and link using > "-lmysqlclient" will end up with a shared library dependency on either > libmysqlclient.so.X or libmariadbclient.so.X depending on the default > defined by the release team at build time. These will be provided by > the libmysqlclient18 (soon to be libmysqlclient20) and > libmariadbclient18 packages, which will be co-installable. Packages > which require particular functionality available from only one of the > forks may Build-Depend directly on libmysqlclient-dev or > libmariadbclient-dev and then link using "-lmysqlclient" or > "-lmariadbclient" respectively. Again, please get in touch if this > applies to you. See above. So this one could still use libmysqlclient-dev? Or we keep a working version with MariaDB, but then again there's other packages like mysql-workbench also wanting 1.1.7 (and thus MySQL 5.7)... > The default-mysql-* metapackages will be uploaded to Experimental soon > and to Unstable once we are confident there are no regressions. Once > they are available in Unstable, we will announce this on I have seen those accepted in unstable this morning so.. :) Regards, Rene
Introducing default-mysql-* metapackages
Hello maintainers of packages that depend in MySQL/MariaDB! TL;DR; We will soon ask you to change packages that depend on MySQL or MariaDB as follows: BEFORE: Build-Depends: libmysqlclient-dev AFTER: Build-Depends: default-libmysqlclient-dev BEFORE: Depends: mysql-server | virtual-mysql-server OR Depends: mariadb-server | virtual-mysql-server AFTER: Depends: default-mysql-server | virtual-mysql-server BEFORE: Depends: mysql-client | virtual-mysql-client OR Depends: mariadb-client | virtual-mariadb-client AFTER: Depends: default-mysql-client | default-mysql-client You can already test this in experimental. We will announce when you should do this in unstable. Details follow: The release team decided earlier in the spring that MariaDB should be made the default MySQL variant in Debian. The release team also wished to have a facility that allows easy switching of the default. Therefore we are now about to introduce the following metapackages from the mysql-defaults source package: - default-mysql-server - default-mysql-server-core - default-mysql-client - default-mysql-client-core - default-libmysqlclient-dev All maintainers of packages that currently depend directly on mysql-server, mariadb-server, or any of the other packages in these series, will at a later time be asked to update the dependencies in their packages to point to default-mysql-* instead. Installing the metapackage default-mysql-server will pull in mariadb-server-10.0. Users who had mysql-server-5.6 will have it removed and replaced by the MariaDB equivalent on upgrade. Note that once you have switched to MariaDB, it might not possible to convert your in-place database files back to MySQL automatically, since Oracle does not maintain tools to convert possible MariaDB features present in the binary format. Please back up your data first if you wish to switch or experiment. Manual dump/import is the most reliable way to import data from one installation to another. A virtual package scheme virtual-mysql-* already exists since 2013, and will continue to exist. All MySQL variants in Debian (and outside in 3rd party repositories too) have Provides for these virtual-mysql-* packages. Maintainers can must use "Depends: default-mysql-server | virtual-mysql-server" if their package can be satisfied by any MySQL variant (Oracle, MariaDB, Percona, mysql-wsrep). The first dependency should be default-mysql-*, which is a metapackage, that in turn depends on exactly one option, which for now is MariaDB. If a maintainer knows that his/her package only works with one variant, then the package can depend directly on that package and not use the default-mysql-* (matches one) or virtual-mysql-* (matches any) schemes. Please get in touch if this applies to you. At the moment there should be no such packages, but in the future cases like this can arise when MySQL and MariaDB develop diverging feature sets. Packages built against default-mysqlclient-dev and link using "-lmysqlclient" will end up with a shared library dependency on either libmysqlclient.so.X or libmariadbclient.so.X depending on the default defined by the release team at build time. These will be provided by the libmysqlclient18 (soon to be libmysqlclient20) and libmariadbclient18 packages, which will be co-installable. Packages which require particular functionality available from only one of the forks may Build-Depend directly on libmysqlclient-dev or libmariadbclient-dev and then link using "-lmysqlclient" or "-lmariadbclient" respectively. Again, please get in touch if this applies to you. Users that want to rebuild packages against a different variant of lib*client-dev for experimenting and testing locally should prefer using a locally modified default-libmysqlclient-dev over modifying each client application source package individually. The default-mysql-* metapackages will be uploaded to Experimental soon and to Unstable once we are confident there are no regressions. Once they are available in Unstable, we will announce this on debian-devel-announce@ officially and later mass file bugs for packages that have not updated their dependencies in a reasonable time otherwise. If you wish to participate in testing or finalizing this scheme, please reply to this thread or write to pkg-mysql-maint@. On behalf ot the pkg-mysql team, - Otto
