Bug #56150 Conflict between "shared" and "shared-compat" RPM should be avoided
Submitted: 20 Aug 2010 16:08 Modified: 24 Sep 2010 18:03
Reporter: Joerg Bruehe Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Packaging Severity:S3 (Non-critical)
Version:all OS:Linux (RPM packages)
Assigned to: Joerg Bruehe CPU Architecture:Any
Triage: Triaged: D3 (Medium) / R2 (Low) / E2 (Low)

[20 Aug 2010 16:08] Joerg Bruehe
We have always offered the client libraries in two RPMs:
- the current version in "shared",
- the current and all previous versions (for this platform) in "shared-cpompat".

Taking the example of 5.5.5-m3, these are the contents lists:

> rpm -qlp MySQL-shared-5.5.5_m3-1.sles11.x86_64.rpm

> rpm -qlp MySQL-shared-compat-5.5.5_m3-1.sles11.x86_64.rpm

This works, but it causes problems in two cases:

1) If a customer needs the current version, s/he installs "shared".
   If later some application is installed which was linked against a previous version of MySQL, they now need "shared-compat" to get the old libraries.
Installing "shared-compat" will conflict with "shared", because both offer the current version (in this example: 16) of the client library.
This can be overcome only by using the "force" option of RPM, or by first uninstalling "shared" (which will break dependencies).

2) If a customer has installed "shared-compat" and then removes the old
   applications, s/he cannot uninstall "shared-compat" as long as current applications are installed.
Again, "force" must be used, and/or dependencies will be broken.

How to repeat:
Just try it ...

Suggested fix:
Make "shared-compat" RPMs become true to their name:
They are *only* for compatibility with older versions of MySQL.

"shared-compat" RPMs should contain only previous versions of the client libraries (in the example of 5.5: versions 12, 14, and 15) but not the current (16).
Then, "shared-compat" can be installed even though "shared" is already installed (no conflict on library version 16),
and it can be uninstalled when old applications are removed (or upgraded) without breaking current applications (as version 16 will not be affected).
[25 Aug 2010 8:34] Daniel Fischer
Looks good.
[2 Sep 2010 10:28] Jonathan Perkin
Looks fine to me.
[9 Sep 2010 15:45] Joerg Bruehe
Pushed to the tools tree on Sep 2,
effective for 5.5.6 and all newer builds.

Docs Team: Sorry about the late notice.
This is a functional change!
For a description, see the "suggested fix".
[24 Sep 2010 18:03] Paul Dubois
Noted in 5.5.6, 5.6.1 changelogs.

Previously, shared-compat RPMs for Linux contained both the current
and previous client library versions for the target platform. Thus,
the package contents overlapped with shared RPMs, which contain only
the current client library version. This can result in problems in
two cases:

* When the shared RPM is installed but later it is determined that the
  shared-compat RPM is needed (an application is installed that was
  linked against an older client library). Installing the shared-compat
  RPM results in a conflict because both include the current library
  version. This can be overcome by using the --force option to RPM, or
  by first uninstalling the shared RPM (which breaks dependencies).

* When the shared-compat RPM is installed, but old applications that
  require it are removed or upgraded to the current library version. In
  this case, shared-compat cannot be replaced with shared as long as
  current applications are installed. This can be overcome by using the
  --force option to RPM, which incurs the risk of breaking

Now the shared-compat RPMs include only older client library versions
and no longer include the current version, so that the shared and
shared-compat RPM contents no longer overlap. The shared-compat RPM
can be installed even if the shared RPM is installed, without
producing conflicts related to the current library version. The
shared-compat RPM can be uninstalled when old applications are
removed or upgraded to the current library version, without breaking
applications that already use the current library version.

If you previously installed the shared-compat RPM because you needed
both the current and previous libraries, you should install both the
shared and shared-compat RPMs now.
[13 Apr 2011 12:26] Edward shaw
This problem happens again on 5.6.2 m5
Plz fix it!
[13 Apr 2011 15:09] Joerg Bruehe
This problem *is* solved, but there was bad timing when several fixes met in the 5.6.2 build:

- The one fix is that "shared-compat" and "shared" RPMs must not have overlapping contents (this bug).
- The other fix is that the change from autotools (used up to MySQL 5.1, and in early 5.5 versions) to cmake (later MySQL 5.5, and all 5.6 versions) had an effect on the ABI which required to change the library version number (bug#60061).

That second fix affected two places, independent changes:
- In the sources, the library version number must be set to 18.
- In the script that creates the "shared-compat" RPMs, the version 16 library (taken from MySQL 5.1) must be included.

The bad timing was that in the 5.6.2 build the second change was used (so a version 16 library from 5.1 is provided), but the first didn't make it (so the library built with 5.6.2 is also still version 16).
This is of course inconsistent, and we apologize.
[22 Mar 2012 17:45] Joerg Bruehe
My sincere apologies:

When I fixed that bug, I forgot to adapt the meta information.
This was later reported as bug#60855, but not realized properly.
This change has now been done:
Starting from versions 5.5.22 and 5.6.5, "shared" and "shared-compat"
RPMs will be able to coexist on a machine, without using "--force"
or other means.