[debian-mysql] Bug#918988: libmariadbclient18: conflict with libmysqlclient18

[Bernard Massot]

Package: libmariadbclient18
Version: 10.1.26-0+deb9u1
Severity: normal

Dear Maintainer,

On a web server running Apache, I'm using OCS inventory (using the
ocsinventory-server Debian package), through mod_perl. OCS inventory
uses libdbd-mysql-perl, which depends on libmariadbclient18.

This Apache instance also runs mod_php, using php5-mysql, which depends
on libmysqlclient18.

After upgrading libmariadbclient18 from 10.1.26-0+deb9u1 to
10.1.37-0+deb9u1, requests to the OCS inventory server were making Apache
crash, leaving "child pid #### exit signal Segmentation fault (11)"
messages in Apache error log files. As a result, Apache was returning
500 HTTP error instead of expected response from OCS inventory.

Downgrading libmariadbclient18 to 10.1.26-0+deb9u1 made everything work
again.


On another server running Apache, I'm using django through mod_wsgi. My
django app was depending on the mysqlclient Python module (provided by
pip in a virtualenv, not by a Debian package), which contained a .so
file linked with libmariadbclient18 (the one in
/usr/lib/x86_64-linux-gnu).

This same Apache instance also runs mod_php, using php5-mysql, which
depends on libmysqlclient18.

After upgrading libmariadbclient18 from 10.1.26-0+deb9u1 to
10.1.37-0+deb9u1, requests to the django web site were making Apache
crash, leaving "child pid #### exit signal Segmentation fault (11)"
messages in Apache error log files. As a result, Apache was returning
500 HTTP error instead of expected response from django.

Downgrading libmariadbclient18 to 10.1.26-0+deb9u1 made everything work
again. Using libmariadbclient18 10.1.37-0+deb9u1 but disabling mod_php
also worked.
I eventually kept libmariadbclient18 10.1.37-0+deb9u1 but installed
libmysqlclient-dev instead of libmariadbclient-dev, and rebuilt
mysqlclient Python module with libmariadbclient-dev. Now the .so file
from mysqlclient is linked with libmysqlclient18, not with
libmariadbclient18 anymore. This way mod_wsgi and mod_php successfully
run in the same Apache instance, while using libmariadbclient18
10.1.37-0+deb9u1.


As a whole, it seems libmysqlclient and libmariadbclient coexisted
peacefully with 10.1.26-0+deb9u1, but don't since 10.1.37-0+deb9u1.

While trying to debug my wsgi crash, I read some explanations about
conflicting symbols. I don't now very well how this whole symbols and
dynamic libraries stuff works, but I remarked this :
* with 10.1.26-0+deb9u1:
$ nm -D /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 | egrep 'lib(mariadb|mysql)client_18'
0000000000000000 A libmariadbclient_18
$ nm -D /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 | egrep 'lib(mariadb|mysql)client_18'
0000000000000000 A libmysqlclient_18
$

* with 10.1.37-0+deb9u1:
$ nm -D /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 | egrep 'lib(mariadb|mysql)client_18'
0000000000000000 A libmariadbclient_18
0000000000000000 A libmysqlclient_18
$ nm -D /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 | egrep 'lib(mariadb|mysql)client_18'
0000000000000000 A libmysqlclient_18
$

So I wonder if new libmariadbclient declaring the same mysql "things" as
libmysqlclient could be the reason of the crashes.