| 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 |
[20 Aug 2010 16:08]
Joerg Bruehe
[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 dependencies. 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.
