Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Fix
-
10.3(EOL), 10.4(EOL), 10.5, 10.6
-
None
Description
If was discovered that the contents of /usr/share/mysql/charsets in MySQL 8.0 is incompatible with previous versions of MySQL and MariaDB. This causes issues on e.g. Ubuntu, where users have both MySQL 8.0 and MariaDB 10.3 available in the repositories (in Ubuntu 20.04). Both of the servers cannot be co-installed at the same time, but some parts of the clients can, and certainly software compiled against on client library can run with the other.
If was reported that if MythTV is compiled with libmysqlclient21, it will crash when running when /usr/share/mysql/charsets from MariaDB 10.3 is installed.
To mitigate this diversion in /usr/share/mysql/charsets compatibility, next version of MariaDB (10.5 or 10.6) could start using charsets in its own path, e.g. /usr/share/mariadb/charsets
See also:
- https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1877504 (specifically states "after upgrade libmysqlclient21 from 8.0.19-0ubuntu5 to 8.0.20-0ubuntu0.20.04.1")
- duplicate: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1877183
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961672
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
If was discovered that the contents of /usr/share/mysql/charsets in MySQL 8.0 is incompatible with previous versions of MySQL and MariaDB. This causes issues on e.g. Ubuntu, where users have both MySQL 8.0 and MariaDB 10.3 available in the repositories (in Ubuntu 20.04). Both of the servers cannot be co-installed at the same time, but some parts of the clients can, and certainly software compiled against on client library can run with the other.
If was reported that if MythTV is compiled with libmysqlclient21, it will crash when running when /usr/share/mysql/charsets from MariaDB 10.3 is installed. To mitigate this diversion in /usr/share/mysql/charsets compatibility, next version of MariaDB (10.5 or 10.6) could start using charsets in its own path, e.g. /usr/share/mariadb/charsets See also: * https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1877504 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961672 |
If was discovered that the contents of /usr/share/mysql/charsets in MySQL 8.0 is incompatible with previous versions of MySQL and MariaDB. This causes issues on e.g. Ubuntu, where users have both MySQL 8.0 and MariaDB 10.3 available in the repositories (in Ubuntu 20.04). Both of the servers cannot be co-installed at the same time, but some parts of the clients can, and certainly software compiled against on client library can run with the other.
If was reported that if MythTV is compiled with libmysqlclient21, it will crash when running when /usr/share/mysql/charsets from MariaDB 10.3 is installed. To mitigate this diversion in /usr/share/mysql/charsets compatibility, next version of MariaDB (10.5 or 10.6) could start using charsets in its own path, e.g. /usr/share/mariadb/charsets See also: * https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1877504 (specifically states "after upgrade libmysqlclient21 from 8.0.19-0ubuntu5 to 8.0.20-0ubuntu0.20.04.1") * duplicate: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1877183 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961672 |
Is there some build log or something where I could see the full file list of Fedora?
I can't find any configuration option for the charsets path specifically. Does this mean that the entire /usr/share/mysql should be moved to /usr/share/mariadb?
Build logs output a list of all packages and the files they include in autobake-deb.sh. See as an example the end of the log at http://buildbot.askmonty.org/buildbot/builders/kvm-deb-bionic-amd64/builds/4850/steps/compile/logs/stdio
The cmake/install_layout.cmake implies that both RPM and DEB are configured to install their stuff in /usr/share/mysql:
#
|
# RPM layout
|
#
|
..
|
SET(INSTALL_MYSQLSHAREDIR_RPM "share/mysql")
|
SET(INSTALL_SUPPORTFILESDIR_RPM "share/mysql")
|
> I have a set of mariadb packages (provided by the operating system) installed on my Fedora box:
Are you now talking about what we have in github.com/mariadb/server 10.5 and publish at downloads.mariadb.org or something else? This issue is about fixing stuff in upstream MariaDB 10.5 (or 10.6) and comments about something else don't help much in debugging this issue 
Hi Otto. I think Fedora overrides the entire /share directory:
$ rpm -ql mariadb-common-10.3.22-1.fc31.x86_64
|
/usr/share/doc/mariadb
|
/usr/share/mariadb
|
/usr/share/mariadb/charsets
|
/usr/share/mariadb/charsets/Index.xml
|
/usr/share/mariadb/charsets/README
|
/usr/share/mariadb/charsets/armscii8.xml
|
/usr/share/mariadb/charsets/ascii.xml
|
/usr/share/mariadb/charsets/cp1250.xml
|
/usr/share/mariadb/charsets/cp1251.xml
|
/usr/share/mariadb/charsets/cp1256.xml
|
/usr/share/mariadb/charsets/cp1257.xml
|
/usr/share/mariadb/charsets/cp850.xml
|
/usr/share/mariadb/charsets/cp852.xml
|
/usr/share/mariadb/charsets/cp866.xml
|
/usr/share/mariadb/charsets/dec8.xml
|
/usr/share/mariadb/charsets/geostd8.xml
|
/usr/share/mariadb/charsets/greek.xml
|
/usr/share/mariadb/charsets/hebrew.xml
|
/usr/share/mariadb/charsets/hp8.xml
|
/usr/share/mariadb/charsets/keybcs2.xml
|
/usr/share/mariadb/charsets/koi8r.xml
|
/usr/share/mariadb/charsets/koi8u.xml
|
/usr/share/mariadb/charsets/latin1.xml
|
/usr/share/mariadb/charsets/latin2.xml
|
/usr/share/mariadb/charsets/latin5.xml
|
/usr/share/mariadb/charsets/latin7.xml
|
/usr/share/mariadb/charsets/macce.xml
|
/usr/share/mariadb/charsets/macroman.xml
|
/usr/share/mariadb/charsets/swe7.xml
|
[bar@home server.10.5]$ rpm -ql mariadb-errmsg-10.3.22-1.fc31.x86_64
|
/usr/share/mariadb/czech
|
/usr/share/mariadb/czech/errmsg.sys
|
/usr/share/mariadb/danish
|
/usr/share/mariadb/danish/errmsg.sys
|
/usr/share/mariadb/dutch
|
/usr/share/mariadb/dutch/errmsg.sys
|
/usr/share/mariadb/english
|
/usr/share/mariadb/english/errmsg.sys
|
/usr/share/mariadb/errmsg-utf8.txt
|
/usr/share/mariadb/estonian
|
/usr/share/mariadb/estonian/errmsg.sys
|
/usr/share/mariadb/french
|
/usr/share/mariadb/french/errmsg.sys
|
/usr/share/mariadb/german
|
/usr/share/mariadb/german/errmsg.sys
|
/usr/share/mariadb/greek
|
/usr/share/mariadb/greek/errmsg.sys
|
/usr/share/mariadb/hindi
|
/usr/share/mariadb/hindi/errmsg.sys
|
/usr/share/mariadb/hungarian
|
/usr/share/mariadb/hungarian/errmsg.sys
|
/usr/share/mariadb/italian
|
/usr/share/mariadb/italian/errmsg.sys
|
/usr/share/mariadb/japanese
|
/usr/share/mariadb/japanese/errmsg.sys
|
/usr/share/mariadb/korean
|
/usr/share/mariadb/korean/errmsg.sys
|
/usr/share/mariadb/norwegian
|
/usr/share/mariadb/norwegian-ny
|
/usr/share/mariadb/norwegian-ny/errmsg.sys
|
/usr/share/mariadb/norwegian/errmsg.sys
|
/usr/share/mariadb/polish
|
/usr/share/mariadb/polish/errmsg.sys
|
/usr/share/mariadb/portuguese
|
/usr/share/mariadb/portuguese/errmsg.sys
|
/usr/share/mariadb/romanian
|
/usr/share/mariadb/romanian/errmsg.sys
|
/usr/share/mariadb/russian
|
/usr/share/mariadb/russian/errmsg.sys
|
/usr/share/mariadb/serbian
|
/usr/share/mariadb/serbian/errmsg.sys
|
/usr/share/mariadb/slovak
|
/usr/share/mariadb/slovak/errmsg.sys
|
/usr/share/mariadb/spanish
|
/usr/share/mariadb/spanish/errmsg.sys
|
/usr/share/mariadb/swedish
|
/usr/share/mariadb/swedish/errmsg.sys
|
/usr/share/mariadb/ukrainian
|
/usr/share/mariadb/ukrainian/errmsg.sys
|
As said, info about downstream Fedora without info what actually upstream github.com/mariadb/server produces isn't helpful, it is just a distraction.
> Are you now talking about what we have in github.com/mariadb/server 10.5 and publish at downloads.mariadb.org or something else?
Yes, I'm talking about the official sources available either from https://github.com/MariaDB/server or from https://downloads.mariadb.org/.
The instructions like INSTALL_MYSQLSHAREDIR_RPM in cmake/install_layout.cmake set the default value, which can be overwritten by a package maintainer.
I think you don't have to wait for MariaDB to fix the default value. It should be possible to set a non-default value when building a deb file.
Fixing the default value sounds like a good idea for me though.
This is Ubuntu packaging bug.
MySQL developers are fully aware that 8.0 has introduced incompatible changes into *.sys files and broke backward compatibility, and that these files cannot be used by older libraries.
This is why MySQL 8.0 installs *.sys files into /usr/share/mysql-8.0 to make it possible to have old and new libraries installed side by side.
Apparently Ubuntu maintainers decided to override this and put new incompatible files over old ones. And they got this bug.
MariaDB sys files are compatible with previous releases of MySQL and MariaDB, that's why they should go into the old location.
| Component/s | Platform Debian [ 10136 ] | |
| Fix Version/s | N/A [ 14700 ] | |
| Resolution | Won't Fix [ 2 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
As documentation, here is proof of Sergei's claim above:
# localized error msgs
|
usr/share/mysql-@MYSQL_BASE_VERSION@/*/errmsg.sys
|
usr/share/mysql-@MYSQL_BASE_VERSION@/messages_to_error_log.txt
|
usr/share/mysql-@MYSQL_BASE_VERSION@/messages_to_clients.txt
|
usr/share/mysql-@MYSQL_BASE_VERSION@/charsets/*.xml
|
usr/share/mysql-@MYSQL_BASE_VERSION@/charsets/README
|
| Summary | MySQL 8.0 / libmysqlclient21 incompatible with MariaDB /usr/share/mysql/charsets | MySQL 8.0 / libmysqlclient21 incompatible it's own libmysqlclien20 and with MariaDB /usr/share/mysql/charsets |
| Workflow | MariaDB v3 [ 109241 ] | MariaDB v4 [ 157867 ] |
I have a set of mariadb packages (provided by the operating system) installed on my Fedora box:
$ rpm -ql mariadb-common-10.3.22-1.fc31.x86_64/usr/share/doc/mariadb/usr/share/mariadb/usr/share/mariadb/charsets/usr/share/mariadb/charsets/Index.xml/usr/share/mariadb/charsets/README/usr/share/mariadb/charsets/armscii8.xml/usr/share/mariadb/charsets/ascii.xml...I'm not 100% sure, but it seems the problem is to be fixed by the package maintainer, by passing a proper path value when compiling the package.
In Fedora it seems to have been already fixed, according to the above `rpm -ql` output.