Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 666750 - =dev-db/mariadb-10.1.34 should possibly prefer mariadb-connector-c over mysql-connector-c
Summary: =dev-db/mariadb-10.1.34 should possibly prefer mariadb-connector-c over mysql...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux MySQL bugs team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-22 09:43 UTC by Jaco Kroon
Modified: 2020-03-29 07:27 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaco Kroon 2018-09-22 09:43:33 UTC
Hi,

I've been seeing all kinds of issues with mysql-connector-c in combination with mariadb off late.  Mostly "random" segfaults.  Not sure if it's simply mysql-connector-c being broken, but switching my systems to mariadb-connector-c[mysqlcompat] resolved a number of my problems.

The dev-db/mariadb ebuilds however forces use of mysql-connector-c where I've now started using dev-db/mariadb-connector-c instead.

I can see two possible resolutions:

1.  Depend on || ( dev-db/mariadb-connector-c dev-db/mysql-connector-c )
2.  Depend on virtual/libmysqlclient

Does mariadb actually require client-libs at all?  I believe it already has it's own client built in, which may or may not relate to bug #649924
Comment 1 Brian Evans (RETIRED) gentoo-dev 2018-09-23 00:54:36 UTC
mariadb-connector-c includes its own runtime problems.

It is pthread_once. So, while an app can compile calling the database initialization multiple times (or in a loop), it will flat out fail at runtime.
Comment 2 Jaco Kroon 2018-09-23 05:26:21 UTC
Having no segfaults currently with mariadb-connector-odbc+mariadb-connector-c compared to numerous segfaults in libmysqlclient with mysql-connector-odbc+mysql-connector-odbc (myodbc).
Comment 3 Brian Evans (RETIRED) gentoo-dev 2018-09-23 13:31:52 UTC
(In reply to Jaco Kroon from comment #2)
> Having no segfaults currently with
> mariadb-connector-odbc+mariadb-connector-c compared to numerous segfaults in
> libmysqlclient with mysql-connector-odbc+mysql-connector-odbc (myodbc).

Segfaults are not the issue.  Apps may just flat out not work saying connection refused or similar.
Comment 4 Jaco Kroon 2018-09-23 14:41:22 UTC
Ok.  So based on annoyance factor of deployment I got things to work with both {mysql,mariadb}-connector-c installed, so mostly things are using mysql-connector-c now, but mariadb-connector-odbc is using is using mariadb-connector-c, a bit of work later to get asterisk to not use MySQL directly but to rather utilize ODBC for all DB connectivity functions I've managed to make things work correctly with current dependencies as in the tree.  As long as all applications use either ODBC of libmysqlclient (but not a combination of both) all should be fine.

I still don't think it's ideal the way it is, but I guess you can close this.  I'd still prefer to see things rather depend on virtual/libmysqlclient where it needs libs, and rather just leave mariadb-connector-c in ~ then if it's really that problematic.

Regarding segfaults, since installing mysql-connector-c I am seeing "random" segfaults in all applications linking libmysqlclient (exim, spamassassin, php-fpm), I've even tried remerging pretty much all of them, even with emerge -e and they still keep exploding from time to time.  With myodbc via mysql-connector-c I was seeing absolutely insane behavior with asterisk (five to ten segfaults a day between 131 instances), since switching all that to mariadb-connector-{c,odbc} that's all working much more reliably (no segfaults over 131 instances since the switch, shutdowns are now happening cleanly where that would be something that would segfault 1 in 3 shutdowns, reloads are now happening sub 3 seconds again where that was timing out @ 15 seconds and/or segfaulting).

Just my experience.
Comment 5 Brian Evans (RETIRED) gentoo-dev 2018-09-23 20:40:49 UTC
Here's what is currently the sequence of events for the libraries:

1) Have packages link to mysql-connector-c and optionally mariadb-connector-c if they can handle it.  There is no way to know if the latter works unless it is fully tested package by package.  They are incompatible at the ABI level (not necessarily API). - Currently in process

2) Remove compatibility packages in dev-db/{mysql,mysql-cluster,mariadb,mariadb-galera,percona-server}. And DROP them from libmysqlclient.

3) Last rites virtual/libmysqlclient as it cannot accomplish what it was intended for in portage.
Comment 6 Forza 2018-11-22 14:32:44 UTC
Perhaps another point of view here.  It seems that Oracle doesn't have a newer package than dev-db/mysql-connector-c-6.1.11. This breaks things with newer MariaDB, at least with dev-db/mariadb-10.3.x. In these cases maybe dev-db/mariadb should depend on dev-db/mariadb-connector-c[mysqlcompat], or things like Dovecot won't work (Malformed Packets when trying to connect).
Comment 7 Larry the Git Cow gentoo-dev 2019-03-15 19:09:18 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5195b2ae5d4c7edf3fea92e2b7f441f0160860b6

commit 5195b2ae5d4c7edf3fea92e2b7f441f0160860b6
Author:     Brian Evans <grknight@gentoo.org>
AuthorDate: 2019-03-15 19:05:28 +0000
Commit:     Brian Evans <grknight@gentoo.org>
CommitDate: 2019-03-15 19:05:28 +0000

    dev-db/mariadb-connector-c: Begin to drop the mysqlcompat USE flag
    
    This library is functionally incompatible and should never have introduced
    this in the first place.
    
    Bug: https://bugs.gentoo.org/show_bug.cgi?id=666750
    Bug: https://bugs.gentoo.org/668560
    Package-Manager: Portage-2.3.62, Repoman-2.3.12
    Signed-off-by: Brian Evans <grknight@gentoo.org>

 .../mariadb-connector-c-3.0.9.ebuild                | 21 ++-------------------
 .../mariadb-connector-c-9999.ebuild                 | 17 +----------------
 2 files changed, 3 insertions(+), 35 deletions(-)
Comment 8 Jaco Kroon 2020-03-29 07:27:26 UTC
Was due to historic stuff, call it usage misunderstanding if you like.  In principle this has been sorted out.