Bug #80981 "libs-compat" RPMs should be independent of all other subpackages
Submitted: 6 Apr 2016 17:10 Modified: 26 Jun 2019 10:03
Reporter: Jörg Brühe (OCA) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Packaging Severity:S3 (Non-critical)
Version:5.6 and up OS:Linux (EL (RedHat, Oracle, CentOS, ...))
Assigned to: CPU Architecture:Any
Tags: charset, libs-compat, requires, rpm

[6 Apr 2016 17:10] Jörg Brühe
Description:
This is a refinement of bug#75876.

Current "libs-compat" RPMs have a "requires" directive on "libs" which in turn "requires" "common".
In fact, "libs" is not needed, but "common" is, because this RPM brings the "charset/*" files.

Letting the old libraries of "libs-compat" use the current "charsets/*" files is no good idea, because it introduces a coupling between old and new versions:
No version may change path name or structure of those files, because it would break the old libraries when they come via "libs-compat".
This will never be tested, so the problem will show up only on a user installation after upgrade.

The proper course is to make a "libs-compat" RPM totally independent of any other MySQL RPM, let it bring its own "charsets/*" files of its own version.
Then, these files may be changed in any way because all accesses will be within the same version only.

How to repeat:
Check the discussion in bug#75876,
or check the spec file in "rpm-oel" (or "rpm-fedora").

Suggested fix:
When building a "libs-compat" RPM, patch the sources so that the "charsets/*" files are not accessed in "/usr/share/mysql/charsets/" (same path for all versions) but rather in "/usr/share/mysql/charsets-VERSION/".
Also, change the spec file so that a "libs-compat" RPM will contain those files.

I will provide the necessary changes under OCA.
[6 Apr 2016 20:48] Terje Røsten
Hi!

Thanks for the report.

I think files in charset/ are mostly backwards compatible.

It's not only because libs needs charset/ files that these requires are
present.

Consider this:

The mysql-libs shipped in EL6 contains libs, charsets, errmsgs and
/etc/my.cnf (sic!)

MySQL packages are completely different:

 libs is in libs-compat (or libs, it depends on el version og MySQL version) 
 charsets and errmsg are in -common
 /etc/my.cnf is in -server

To install any of the MySQL packages mysql-libs must be replaced by
-libs or -libs-compat *first*.

Something else will lead to file conflicts and endless trouble.

The requires, provides, obsoletes etc are fine tuned to work out of
box, it might have some minor side effects, however it seems to work fine.
[8 Apr 2016 14:39] Jörg Brühe
Hi!
Thanks for the reply and your reasoning.
I do not agree:

You are right that the first step is to install "libs-compat", to get rid of the "libs" provided by EL. (Which must be an "update" action, so that the "obsoletes" is honored.)

With the current dependencies, this will pull "libs" and further "common" as a prerequisite. The only technical requirement is "charsets/*" for those ODBC calls.

As a consequence of "libs-compat" requiring "common", the whole MySQL version is fixed to the current version. I want to get rid of this restriction, so that the server may be upgraded further, or erased and replaced by a tar-ball installation, a labs release, a source build, ...

Once "libs-compat" is stand-alone, the version coupling is gone. The user may now install any version without breaking RPM dependencies.

I have set up a clone on github as "fromdualjb", added a branch "5.6-bug80981" with my change, and created a pull request for you.
OCA is signed and accepted.
[11 Apr 2016 12:09] OCA Admin
Contribution submitted via Github - Fix for bug#80981: Make "libs-compat" stand-alone 
(*) Contribution by Jörg Brühe (Github fromdualjb, mysql-server/pull/69#issuecomment-207942228): I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.

Contribution: git_patch_65795518.txt (text/plain), 7.81 KiB.

[12 Apr 2016 6:11] MySQL Verification Team
Thank you for the report and contribution.

Thanks,
Umesh
[14 Oct 2016 12:41] Terje Røsten
Hi,

I like the idea of moving files to directory which depend on version. However, moving only subdir charset/ seems suboptimal and moving files by hand in spec file seems like hack.

I would rather see this implemented as an build option via cmake variable(s) such that share dir could be set to share/mysql-5.x and end up as /usr/share/mysql-5.x in rpm package. 

Server and all clients, client lib and embedded server and of course MTR (inside build dir and after install) together with cmake machinery with "make install" and friends should respect this setting. Also of interest would be to split server and client share dir completely, making it possible, in the same build, to set share dir for server to share/mysql-5.x and while clients would use share/mysql-client-5.x.
[14 Oct 2016 21:04] Jörg Brühe
Hi!

My immediate need was about "libs-compat", and I wanted to make the change as small as possible - it was to a stable, old version.

Sure, it should be possible to modify some "CMakeLists.txt" to let everything be built with the modified path.

For "charsets/" alone, it seems this would also require modifying "comp_err.c" which has the path as a constant string, not using the "#define CHARSET_DIR" from "include/m_ctype.h".
For the whole "/usr/share/mysql/", I'm sure it is a very invasive change, and finding all affected places will be a tedious task, because "mysql" occurs very often and in completely different contexts.

I don't yet see how to have different directories for server and client in the same build: Both components use the same file "include/m_ctype.h" where "CHARSET_DIR" is defined.
AIUI, this macro would have to be duplicated into "CHARSET_DIR_SERVER" and "CHARSET_DIR_CLIENT", and "mysys/charset.c" would also need some duplication into separate server and client parts.

I might give the first part a try, but only for "charsets/" alone; changing the whole "/usr/share/mysql/" would need more search and analysis effort than my needs justify.
[26 Jun 2019 10:03] Terje Røsten
This is was fixed by:

 https://github.com/mysql/mysql-server/commit/1de595eae9d8eb9310130bb3fba54aa5a5ce7047

Bug#26990531 SUPPORT FOR VERSION NUMBER IN SHARE DIRECTORY

For various reasons some install layouts might want to set
-DINSTALL_MYSQLSHAREDIR=share/mysql-8.0,

Switch RPM to use such layout by default.
Adjust MTR to work with this choice too.