Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf

[nobody]

Package: libmariadb3
Version: 1:10.3.36-0+deb10u1
Severity: normal

Dear Maintainer,

The libmariadb3 package requires mariadb-common, but this last one will modify the /etc/mysql/my.cnf.
The library is not only use on a host having mariadb as a server, this is used on clients or on server with other flavor of mysql , in mytop for exemple.
Installing this on a server using mysql.com packages or perconna packages will alter the server configuration of /etc/mysql/my.cnf


* What led up to the situation?

install of mytop that requires libdbd-mysql-perl => libmariadb3 => mariadb-common

* What exactly did you do (or not do) that was effective (or ineffective)?

As this machine is not a mariadb server but a mysql server installing this caused problems with the my.cnf file, i am locked by this requirement of libmariadb

* What was the outcome of this action?

each apt action return now an error as the package fail : update-alternatives: error: alternative path /etc/mysql/mariadb.cnf doesn't exist

* What outcome did you expect instead?

installing a client library should not require anything on the server side and should not modify server configuration of mariadb or other mysql flavors (imho ;p)



-- System Information:
Debian Release: 10.13
APT prefers oldstable
APT policy: (500, 'oldstable'), (100, 'oldoldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.254-vs2.3.9.12aq (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libmariadb3 depends on:
ii libc6 2.28-10+deb10u1
ii libgnutls30 3.6.7-4+deb10u9
ih mariadb-common 1:10.3.36-0+deb10u1
ii zlib1g 1:1.2.11.dfsg-1+deb10u2

libmariadb3 recommends no packages.

libmariadb3 suggests no packages.

-- no debconf information

[Robie Basak]

On Thu, Sep 22, 2022 at 05:10:05PM +0200, nobody wrote:
> * What outcome did you expect instead?
>
> installing a client library should not require anything on the server side and should not modify server configuration of mariadb or other mysql flavors (imho ;p)

Both MySQL/MariaDB client libraries and MySQL/MariaDB daemons expect and
use /etc/mysql/my.cnf, and many common packages supplied by Debian link
to a MySQL/MariaDB library. So Debian ends up needing to ship a working
/etc/mysql/my.cnf essentially by default. It doesn't matter which side
of the fork is in use - it's necessary either way. Maybe upstream could
separate the two out, but they don't.

MySQL and MariaDB Debian maintainers worked out a way to make it work
regardless of the side of the fork in use using the update-alternatives
mechanism. I think there might still be some implementation bugs in how
they do that exactly, but I don't think they're relevant to what you're
reporting here.

If third parties are shipping apt packages that override some of this,
they need to integrate with distribution packages, not the other way
round. Issues with third party apt repositories aren't normally
considered bugs in Debian. This sounds like an issue with a third party
repository and a bug in their packaging, and not a bug in Debian.
However I'm not entirely sure as you haven't provided a detailed
analysis of why they've been unable to integrate.

I suggest that this bug needs to be either moreinfo or wontfix.

[Ghislain Adnet]

Le 22/09/2022 à 18:12, Robie Basak a écrit :
> On Thu, Sep 22, 2022 at 05:10:05PM +0200, nobody wrote:
>> * What outcome did you expect instead?
>>
>> installing a client library should not require anything on the server side and should not modify server configuration of mariadb or other mysql flavors (imho ;p)
>
> Both MySQL/MariaDB client libraries and MySQL/MariaDB daemons expect and
> use /etc/mysql/my.cnf, and many common packages supplied by Debian link
> to a MySQL/MariaDB library. So Debian ends up needing to ship a working
> /etc/mysql/my.cnf essentially by default. It doesn't matter which side
> of the fork is in use - it's necessary either way. Maybe upstream could
> separate the two out, but they don't.

thanks for your quick answer

So perhaps we could see it another way :
in this particular case i think that a client library, if it find an existing /etc/mysql/my.cnf, should not do anything as it is there adn so everything it need is okay.
There is no need for a client library to change this part if it is here if it only need one to exist.

Perhaps just adding a check
if [[ ! -e /etc/mysql/my.cnf ]]; then
do touch server configuration in /etc/mysql/my.cnf
fi



--
cordialement,
Ghislain ADNET.

[Robie Basak]

On Thu, Sep 22, 2022 at 06:21:34PM +0200, Ghislain Adnet wrote:
> So perhaps we could see it another way :
> in this particular case i think that a client library, if it find an existing /etc/mysql/my.cnf, should not do anything as it is there adn so everything it need is okay.
> There is no need for a client library to change this part if it is here if it only need one to exist.
>
> Perhaps just adding a check
> if [[ ! -e /etc/mysql/my.cnf ]]; then
> do touch server configuration in /etc/mysql/my.cnf
> fi

We use the Debian-system-wide update-alternatives mechanism, which has
standard and known behaviour. Further, third party packaging can simply
integrate with it to provide their own my.cnf as needed. If
/etc/mysql/my.cnf is properly overriden by packaging, even external
packaging, then the client library packages that touch it will leave it
alone.

I don't think it makes sense to introduce extra behaviour that might be
surprising for sysadmins who already know how update-alternatives works
and integrate with it.

Again, note that I'm still speculating here because I don't follow the
exact sequence of events which is causing the third party packaging to
trip up here. If there's something we're doing wrong then we should fix
it, but nothing I've read so far suggests that.

[Robie Basak]

On Thu, Sep 22, 2022 at 05:28:27PM +0100, Robie Basak wrote:
> Again, note that I'm still speculating here because I don't follow the
> exact sequence of events which is causing the third party packaging to
> trip up here. If there's something we're doing wrong then we should fix
> it, but nothing I've read so far suggests that.

Oh, hold on. Is the issue that you've *deleted* /etc/mysql/mariadb.cnf?
If so, then yes, /usr/share/mysql-common/configure-symlinks could
reasonably not call update-alternatives --install to maintain that
"sysadmin choice". It should probably print a warning in this case.

But we should also take care of the "remove" call too, make sure that
also works if the "install" was skipped.

[Ghislain Adnet]

Le 22/09/2022 à 18:37, Robie Basak a écrit :
> On Thu, Sep 22, 2022 at 05:28:27PM +0100, Robie Basak wrote:
>> Again, note that I'm still speculating here because I don't follow the
>> exact sequence of events which is causing the third party packaging to
>> trip up here. If there's something we're doing wrong then we should fix
>> it, but nothing I've read so far suggests that.
>
> Oh, hold on. Is the issue that you've *deleted* /etc/mysql/mariadb.cnf?
> If so, then yes, /usr/share/mysql-common/configure-symlinks could
> reasonably not call update-alternatives --install to maintain that
> "sysadmin choice". It should probably print a warning in this case.

Sorry if i am not clear enough.

in fact /etc/mysql/mariadb.cnf does not exist as there is a mysql server and not a mariadb one.

I have a perconna mysql server running and i want to install mytop that require a perl lib that require libmariad3b, that then, want to replace /etc/mysql/my.cnf with a link to /etc/mysql/mariadb.cnf,
but /etc/mysql/mariadb.cnf does not exist while /etc/mysql/my.cnf exist from the percona packages.

hope that clarify ?

sorry not native english speaker too so...

--
cordialement,
Ghislain ADNET.
AQUEOS.

[Robie Basak]

On Thu, Sep 22, 2022 at 11:32:05PM +0200, Ghislain Adnet wrote:
> in fact /etc/mysql/mariadb.cnf does not exist as there is a mysql server and not a mariadb one.

mariadb-common ships /etc/mysql/mariadb.cnf.

> I have a perconna mysql server running and i want to install mytop that require a perl lib that require libmariad3b, that then, want to replace /etc/mysql/my.cnf with a link to /etc/mysql/mariadb.cnf,

Not necessarily. It integrates with update-alternatives. It will link
from /etc/mysql/my.cnf to /etc/mysql/mariadb.cnf unless overridden by
another package or by the user.

> but /etc/mysql/mariadb.cnf does not exist while /etc/mysql/my.cnf exist from the percona packages.

You're entitled to remove /etc/mysql/mariadb.cnf and I think in that
case the packaging should respect that and not break. So there might be
something that could be improved here.

However, I did some investigation, and found that if you set
update-alternatives correctly to use a different my.cnf (in my testing I
used my.cnf.fallback as it was already there), then the packaging does
not break. So, as far as I can tell, the problem here lies with your
third party packaging not correctly integrating with distribution
packaging by using update-alternatives correctly to supply my.cnf. I
think you need to report this bug to them, and it isn't an issue in
Debian.