MySQL Bugs: #44575: rpm packages with version numbers in paths

Bug #44575	rpm packages with version numbers in paths
Submitted:	30 Apr 2009 13:23	Modified:	1 Dec 2016 13:25
Reporter:	Susanne Ebrecht	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Packaging	Severity:	S4 (Feature request)
Version:	5.0, 5.1, 5.5, 6.0	OS:	Linux (RPM-Linux)
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
There are some use cases for which is it helpful to have two different MySQL instances installed on the same machine under same OS.

One example customers and users have is during upgrade:
You have a fine working 5.0 system and want to upgrade to 5.1.
This means you have to remove 5.0 and install 5.1.
Let us say, your upgrade didn't work ... now you have to remove 5.1 again and install 5.0.

That is very annoying and not a really good solution at all.

Debian already find a better solution here. Usually, when you install debian packages, then the version numbers are given in the path. So it is easy possible to install more instances on the same system.

For example: instead of just "mysql" it is "mysql-5.0" and "mysql-5.1".

Also on Windows it is possible to install more MySQL instances by using the MySQL packages on same Windows system.

It just should be possible by using the MySQL RPM packages too.

Debian also detects the port via automatism and set the port to the next higher number if another instance already is using the port. That is a nice feature too but not so important.

More important is, that it will be possible to use MySQL RPM and install more then one instance on same system.

How to repeat:
It is a feature request

Suggested fix:
Add version numbers to the paths.

As you write, Debian's system makes more sense; however, we still can't change what RPM-based distributions do. Our packages are meant to replace those that ship with the OS and hence have to use the same scheme.

> Our packages are meant to replace those that ship with the OS and hence have to use the same scheme.

There are many ways to work around this, using alternative or subpackages and a wrapper package which depends on at least one underlying package being installed and fixes "links" so that it appears to behave as normal.

The real question is for larger installations or installations where more than one mysql instance is installed the "single" package located in a single "location" is cumbersome.

It also means that you can't run multiple versions of mysql on the same server without reverting back to the binary tarballs you provide, or building from source. That too is cumbersome.

It also means that a major version upgrade (5.0 to 5.1) may have real issues as part of this upgrade procedure MAY require switching binaries. Not everyone has the time or the disk space to do a mysqldump of the old version and reload it into the new version. Not when the db is over 600GB.

So really my comment came from the fact that for several types of mysql customers this functionality would be useful. I also understand it would require a change from existing behaviour. If that's not possible we just have to workaround the current limitations which is unfortunate.

I started looking into this.

AIUI, the main problem is not the path to the binaries, this could be solved by manipulating the directory (add a version part, probably just the release family like "5.5", not the exact version "5.5.11").

Rather, I lack all ideas how to handle the central files accesed by a known path name, most prominent example being the startup script "/etc/init.d/mysql".

Yes, I tried to look into the Debian packages to get ideas or an example to follow, but AFAICS they also use that fixed name.
And even though changes in that script may be minimal, I dare not overwrite it (not to mention that this would cause a conflict on RPM installation).

I will continue looking ...

I'm looking at this, but I'm not too optimistic till now.

The issue is not so much about having the release series number (5.1, 5.5) in the path, it is more about the system integration and those files which have really fixed names currently, like "/etc/init.d/mysql":
Do you really want to have different start/stop script names by release series?

And if these names do not get versioned, we will have RPM file conflicts on these files, even if we manage to make them version-agnostic so that a new script can also interact with old server processes (which might become a thrilling exercise for QA).

As regards Debian packages:
I would gladly inspect how they do this - if they really did.
At least the ones I am currently looking at (those for "Lenny" aka Debian 5) do not show any sign of such a capability.

I will continue investigation somewhat, but currently I don't see a way to achieve this without doing a major change in the interaction structure of scripts and processes, or leaving it to the user to manage those files (rename them) and handle conflicts.

Hi. You raise various questions but don't think you really understand the problem.

For simple installations you may be quite happy to have a single version of MySQL installed. When you upgrade you use the normal rpm -Uvh MySQL-whatever.rpm to get that done.

On larger installations you may want to have multiple versions of MySQL installed for several different reasons:
1. you may have multiple instances running on the same server and want to upgrade them independently
2. you may want to be able to "switch" binaries quickly when doing the upgrade. This is especially true when you need to do a major version upgrade as you may need to run "old binary" scripts, or "new binary scripts" as part of the upgrade process and switching rpms (with a single version of MySQL installed) just does not work with the current design.

You may want to be backwards compatible with the current OS packages. That's fine also but there are needs for supporting the install of multiple versions at once. When doing major version upgrades you are asked to use the new binaries to check if anything needs to be done, but then told that you must use the old binaries to do the mysqldump of the table which you have to reload back in with the new binaries. If you only have a single MySQL rpm package then this does not work well.

So what I was suggesting is that it's possible, like it is with java or kernel packages to have multiple versions of the binaries installed at once. Obviously this must be done in different locations.

Then you rightly mention the issue of startup scripts etc. I believe java does this by having symlinks from the generic /usr/bin/java to the specific version that is wanted (maybe via the alternatives packaging?). you should be able to do something similar with mysql and have at least a basic single /etc/init.d/mysql to startup a single instance.

It would be nice to extend this so that this may be able to startup multiple instances, then you can use this to startup different instances using different versions of mysql. Oracle's /etc/oratab seems to work quite well in this respect and currently there is not an official mechanism for starting multiple instances AFAIK, or if there is it's different to the "standard" way of starting a single instance. So not ideal.

So these were the points I was trying to bring up when first creating this ticket 2 years ago. So far it seems without making much progress.

Posted by developer:
 
By using MySQL Repos is simple to switch between releases, parallel install of multiple MySQL versions 
by RPMS will not be implemented.