[gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

[gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 1063 bytes --]

I have a plan I would like some eyes on...

I want to gradually *BAN* the use of virtual/mysql and
virtual/libmysqlclient as dependencies.

To accomplish this, force dev-db/mysql-connector-c to be the only souce
of libmysqlclient.so.

Packages that choose to support  libmariadb.so instead can include a
libmariadb USE to hook up to dev-db/mariadb-connector-c that will be
introduced (and they can live side-by-side).  The motivation for this
could be licensing with libmariadb being LGPL instead of GPL.  This is
similar to ffmpeg/libav, except the libraries can co-exist.

The current providers of virtual/mysql would get a new USE flag that is
MASKED for all users for the transition period and pull in the lib
package(s) when that USE is disabled.

virtual/mysql would become a server reference for USERS only.  It would
be a QA warning violation to depend directly on virtual/mysql as it can
live anywhere.

virtual/libmysqlclient would be last-rite as it doesn't work as intended

That about sums it up.

Brian
MySQL team lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

On Tue, Feb 13, 2018 at 09:32:32PM -0500, Brian Evans wrote:
> I have a plan I would like some eyes on...
> 
> I want to gradually *BAN* the use of virtual/mysql and
> virtual/libmysqlclient as dependencies.
Overall I agree, but there's some slight concerns I have.

> To accomplish this, force dev-db/mysql-connector-c to be the only souce
> of libmysqlclient.so.
>
> Packages that choose to support  libmariadb.so instead can include a
> libmariadb USE to hook up to dev-db/mariadb-connector-c that will be
> introduced (and they can live side-by-side).  The motivation for this
> could be licensing with libmariadb being LGPL instead of GPL.  This is
> similar to ffmpeg/libav, except the libraries can co-exist.
Have all the concerns about using slightly different libmysqlclient.so
builds been resolved? Esp for pre-built binaries (I don't know if there
are any left in the tree).

> The current providers of virtual/mysql would get a new USE flag that is
> MASKED for all users for the transition period and pull in the lib
> package(s) when that USE is disabled.
> 
> virtual/mysql would become a server reference for USERS only.  It would
> be a QA warning violation to depend directly on virtual/mysql as it can
> live anywhere.
This part worries me slightly. I do understand that mysql-embedded is
retired entirely, but apps that spun up their own local mysqld instance
would still be affected this this change.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

[Francesco Riosa]

[-- Attachment #1.1: Type: text/plain, Size: 2513 bytes --]


On 14/02/2018 05:37, Robin H. Johnson wrote:
> On Tue, Feb 13, 2018 at 09:32:32PM -0500, Brian Evans wrote:
>> I have a plan I would like some eyes on...
>>
>> I want to gradually *BAN* the use of virtual/mysql and
>> virtual/libmysqlclient as dependencies.
> Overall I agree, but there's some slight concerns I have.
>
>> To accomplish this, force dev-db/mysql-connector-c to be the only souce
>> of libmysqlclient.so.
>>
>> Packages that choose to support  libmariadb.so instead can include a
>> libmariadb USE to hook up to dev-db/mariadb-connector-c that will be
>> introduced (and they can live side-by-side).  The motivation for this
>> could be licensing with libmariadb being LGPL instead of GPL.  This is
>> similar to ffmpeg/libav, except the libraries can co-exist.
> Have all the concerns about using slightly different libmysqlclient.so
> builds been resolved? Esp for pre-built binaries (I don't know if there
> are any left in the tree).
>
>> The current providers of virtual/mysql would get a new USE flag that is
>> MASKED for all users for the transition period and pull in the lib
>> package(s) when that USE is disabled.
>>
>> virtual/mysql would become a server reference for USERS only.  It would
>> be a QA warning violation to depend directly on virtual/mysql as it can
>> live anywhere.
> This part worries me slightly. I do understand that mysql-embedded is
> retired entirely, but apps that spun up their own local mysqld instance
> would still be affected this this change.

Checked a random desktop install and found these packages depending on
virtual/mysql:

vivo@Monfi ~ $ equery d virtual/mysql
 * These packages depend on virtual/mysql:
dev-db/mariadb-10.2.12 (server ? ~virtual/mysql-5.6[embedded=,static=])
dev-libs/apr-util-1.6.1 (mysql ? =virtual/mysql-5*)
dev-libs/cyrus-sasl-2.1.26-r11 (mysql ? virtual/mysql)
dev-libs/redland-1.0.17-r1 (mysql ? virtual/mysql)
kde-apps/akonadi-17.12.2 (mysql ? virtual/mysql)
net-analyzer/net-snmp-5.7.3_p3 (mysql ? virtual/mysql)
net-mail/mailutils-3.4 (mysql ? virtual/mysql)
sci-mathematics/glpk-4.63 (mysql ? virtual/mysql)

It would be interesting to know how their ${*DEPEND} should look after
the change.

Honestly I'd also like to understand the rationale better, why this
change is needed?
Are the implementations of Oracle mysql and Mariadb so different that
it's not possible anymore to consider those equivalent (for what
packages see)?

Thanks in advance,
Francesco


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 3520 bytes --]

On 2/14/2018 9:35 AM, Francesco Riosa wrote:
> 
> On 14/02/2018 05:37, Robin H. Johnson wrote:
>> On Tue, Feb 13, 2018 at 09:32:32PM -0500, Brian Evans wrote:
>>> I have a plan I would like some eyes on...
>>>
>>> I want to gradually *BAN* the use of virtual/mysql and
>>> virtual/libmysqlclient as dependencies.
>> Overall I agree, but there's some slight concerns I have.
>>
>>> To accomplish this, force dev-db/mysql-connector-c to be the only souce
>>> of libmysqlclient.so.
>>>
>>> Packages that choose to support  libmariadb.so instead can include a
>>> libmariadb USE to hook up to dev-db/mariadb-connector-c that will be
>>> introduced (and they can live side-by-side).  The motivation for this
>>> could be licensing with libmariadb being LGPL instead of GPL.  This is
>>> similar to ffmpeg/libav, except the libraries can co-exist.
>> Have all the concerns about using slightly different libmysqlclient.so
>> builds been resolved? Esp for pre-built binaries (I don't know if there
>> are any left in the tree).
>>
>>> The current providers of virtual/mysql would get a new USE flag that is
>>> MASKED for all users for the transition period and pull in the lib
>>> package(s) when that USE is disabled.
>>>
>>> virtual/mysql would become a server reference for USERS only.  It would
>>> be a QA warning violation to depend directly on virtual/mysql as it can
>>> live anywhere.
>> This part worries me slightly. I do understand that mysql-embedded is
>> retired entirely, but apps that spun up their own local mysqld instance
>> would still be affected this this change.
> 
> Checked a random desktop install and found these packages depending on
> virtual/mysql:
> 
> vivo@Monfi ~ $ equery d virtual/mysql
>  * These packages depend on virtual/mysql:
> dev-db/mariadb-10.2.12 (server ? ~virtual/mysql-5.6[embedded=,static=])
> dev-libs/apr-util-1.6.1 (mysql ? =virtual/mysql-5*)
> dev-libs/cyrus-sasl-2.1.26-r11 (mysql ? virtual/mysql)
> dev-libs/redland-1.0.17-r1 (mysql ? virtual/mysql)
> kde-apps/akonadi-17.12.2 (mysql ? virtual/mysql)
> net-analyzer/net-snmp-5.7.3_p3 (mysql ? virtual/mysql)
> net-mail/mailutils-3.4 (mysql ? virtual/mysql)
> sci-mathematics/glpk-4.63 (mysql ? virtual/mysql)
dev-libs/apr-util-1.6.1 (mysql ? dev-db/mysql-connector-c:=)
dev-libs/cyrus-sasl-2.1.26-r11 (mysql ? dev-db/mysql-connector-c:=)
dev-libs/redland-1.0.17-r1 (mysql ? dev-db/mysql-connector-c:=)
kde-apps/akonadi-17.12.2 (mysql ? dev-db/mysql-connector-c:=)
net-analyzer/net-snmp-5.7.3_p3 (mysql ? dev-db/mysql-connector-c:=)
net-mail/mailutils-3.4 (mysql ? dev-db/mysql-connector-c:=)
sci-mathematics/glpk-4.63 (mysql ? dev-db/mysql-connector-c:=)


> 
> It would be interesting to know how their ${*DEPEND} should look after
> the change.
> 
> Honestly I'd also like to understand the rationale better, why this
> change is needed?
> Are the implementations of Oracle mysql and Mariadb so different that
> it's not possible anymore to consider those equivalent (for what
> packages see)?

This is needed for a few reasons:

1) Virtuals cannot rebuild dependencies when there are subslot changes
2) dev-db/mysql-5.7 and dev-db/percona-server-5.7 are prevented from
entering the tree simply due to the client library SOVERSION change.  It
is difficult for the user to swap between server versions.
3) libmariadb.so is a pthread_once library which many other packages are
not expecting.  So they may have to write things two different ways


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]