[gentoo-dev] Deprecation of virtual/libmysqlclient and virtual/mysql as providers for libmysqlclient.so

[gentoo-dev] Deprecation of virtual/libmysqlclient and virtual/mysql as providers for libmysqlclient.so

[Brian Evans]

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

With the current state of the forks of MySQL diverging, the client
libraries are no longer compatible.

Since virtual packages cannot handle rebuilds of subscribed packages
when a consumer changes, the following action is to be taken by all
developers:

If you need libmysqlclient.so, please depend on dev-db/mysql-connector-c.
If you need or can use libmariadb.so, please depend on
dev-db/mariadb-connector-c.

(Yes the above packages coexist just fine.)

Please remove references to virtual/libmysqlclient as it does not work
as I intended (and explained above). This virtual will be last-rites
once nothing depends on it.

Please remove all DEPEND on virtual/mysql where it is used for libraries.
virtual/mysql is the client and server tools *only*.
It is not correct to rely on this for libraries any longer.
A good example for DEPEND is tests where the client/server binaries are run.
RDEPEND for the purpose of running client/server is fine for virtual/mysql.

Almost all of the consumers of virtual/mysql have already been updated
(save mysql-cluster).  Some are already stable.

At a point in the future, likely in 2019, the compatibility DEPEND that
exist in the consumers will be removed and may break packages which are
not updated.

In the coming months, I will try my best to test and report bugs on
packages which I can find.

I welcome any discussion on the details, but this is the only sane move
for Gentoo and the ABI incompatibilities that exist on the client libraries.

Thank you,

Brian Evans


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

Re: [gentoo-dev] Deprecation of virtual/libmysqlclient and virtual/mysql as providers for libmysqlclient.so

[David Seifert]

On Mon, 2018-07-23 at 14:18 -0400, Brian Evans wrote:
> With the current state of the forks of MySQL diverging, the client
> libraries are no longer compatible.
> 
> Since virtual packages cannot handle rebuilds of subscribed packages
> when a consumer changes, the following action is to be taken by all
> developers:
> 
> If you need libmysqlclient.so, please depend on dev-db/mysql-
> connector-c.
> If you need or can use libmariadb.so, please depend on
> dev-db/mariadb-connector-c.
> 
> (Yes the above packages coexist just fine.)
> 
> Please remove references to virtual/libmysqlclient as it does not
> work
> as I intended (and explained above). This virtual will be last-rites
> once nothing depends on it.
> 
> Please remove all DEPEND on virtual/mysql where it is used for
> libraries.
> virtual/mysql is the client and server tools *only*.
> It is not correct to rely on this for libraries any longer.
> A good example for DEPEND is tests where the client/server binaries
> are run.
> RDEPEND for the purpose of running client/server is fine for
> virtual/mysql.
> 
> Almost all of the consumers of virtual/mysql have already been
> updated
> (save mysql-cluster).  Some are already stable.
> 
> At a point in the future, likely in 2019, the compatibility DEPEND
> that
> exist in the consumers will be removed and may break packages which
> are
> not updated.
> 
> In the coming months, I will try my best to test and report bugs on
> packages which I can find.
> 
> I welcome any discussion on the details, but this is the only sane
> move
> for Gentoo and the ABI incompatibilities that exist on the client
> libraries.
> 
> Thank you,
> 
> Brian Evans
> 

How do you plan on dispatching against them at compile/link-time, i.e.
USE=libav/graphicsmagick/libressl?

David

Re: [gentoo-dev] Deprecation of virtual/libmysqlclient and virtual/mysql as providers for libmysqlclient.so

[Brian Evans]

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

On 7/24/2018 12:44 AM, David Seifert wrote:
> On Mon, 2018-07-23 at 14:18 -0400, Brian Evans wrote:
>> With the current state of the forks of MySQL diverging, the client
>> libraries are no longer compatible.
>>
>> Since virtual packages cannot handle rebuilds of subscribed packages
>> when a consumer changes, the following action is to be taken by all
>> developers:
>>
>> If you need libmysqlclient.so, please depend on dev-db/mysql-
>> connector-c.
>> If you need or can use libmariadb.so, please depend on
>> dev-db/mariadb-connector-c.
>>
>> (Yes the above packages coexist just fine.)
>>
>> Please remove references to virtual/libmysqlclient as it does not
>> work
>> as I intended (and explained above). This virtual will be last-rites
>> once nothing depends on it.
>>
>> Please remove all DEPEND on virtual/mysql where it is used for
>> libraries.
>> virtual/mysql is the client and server tools *only*.
>> It is not correct to rely on this for libraries any longer.
>> A good example for DEPEND is tests where the client/server binaries
>> are run.
>> RDEPEND for the purpose of running client/server is fine for
>> virtual/mysql.
>>
>> Almost all of the consumers of virtual/mysql have already been
>> updated
>> (save mysql-cluster).  Some are already stable.
>>
>> At a point in the future, likely in 2019, the compatibility DEPEND
>> that
>> exist in the consumers will be removed and may break packages which
>> are
>> not updated.
>>
>> In the coming months, I will try my best to test and report bugs on
>> packages which I can find.
>>
>> I welcome any discussion on the details, but this is the only sane
>> move
>> for Gentoo and the ABI incompatibilities that exist on the client
>> libraries.
>>
>> Thank you,
>>
>> Brian Evans
>>
> 
> How do you plan on dispatching against them at compile/link-time, i.e.
> USE=libav/graphicsmagick/libressl?
> 
> David
> 

If a maintainer wishes to have a USE flag to link to libmariadb, that's
up to them.

Use of mariadb-connector-c may need patching (for mariadb_config or
mariadb.pc) or build options to look at the other library.  This may be
beneficial for licensing purposes (GPL-2 vs LGPL-2.1)

If such a flag is popular enough, then a global description can be
agreed upon.

Brian


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