Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Introducing default-mysql-* metapackages
194 views
Skip to first unread message
Ondřej Surý
Sep 5, 2016, 3:00:02 AM9/5/16
to
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ý <ond...@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 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 regressions. If you however do encounter
> problems, please report to pkg-mysql-maint@.
>
>
> On behalf ot the pkg-mysql team,
>
> - Otto
> Email had 1 attachment:
> + signature.asc
> 1k (application/pgp-signature)
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ý <ond...@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 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 regressions. If you however do encounter
> problems, please report to pkg-mysql-maint@.
>
>
> On behalf ot the pkg-mysql team,
>
> - Otto
> Email had 1 attachment:
> + signature.asc
> 1k (application/pgp-signature)
Otto Kekäläinen
Sep 5, 2016, 7:40:03 AM9/5/16
to
Hello!
2016-09-05 9:57 GMT+03:00 Ondřej Surý <ond...@sury.org>:
> 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
2016-09-05 9:57 GMT+03:00 Ondřej Surý <ond...@sury.org>:
> 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.
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
Robie Basak
Sep 5, 2016, 2:10:02 PM9/5/16
to
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
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?
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
Clint Byrum
Sep 5, 2016, 6:30:02 PM9/5/16
to
Excerpts from Robie Basak's message of 2016-09-05 18:59:39 +0100:
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.
> 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
>
> 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.
>
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.
Ondřej Surý
Sep 6, 2016, 3:10:02 AM9/6/16
to
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ý <ond...@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
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.
> 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.
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ý <ond...@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
Robie Basak
Sep 7, 2016, 6:20:03 AM9/7/16
to
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
> 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".
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
Ondřej Surý
Sep 7, 2016, 7:10:02 AM9/7/16
to
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ý <ond...@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
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.
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ý <ond...@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
0 new messages