BUG: mysql4 and mysql5 mutually exclusive

[yves@…]

Both share some files and (correct me if I'm wrong) both use $prefix/var/db/mysql

The official binairies used to install as $prefix/mysql-$version/

Since some other ports depend on shared libs, then it could be $prefix/mysql$major to survive between upgrades with $prefix/var/db/mysql$major ?

thanks

[mww@…]

I'm currently trying to get along with something similar for postgresql 7 & 8; I put the stuff in $prefix/include/pgsql7, $prefix/lib/pgsql7/bin etc., then symlink the sql-client to $prefix/bin; maybe something similar can do the trick here w/o polluting $prefix and making the user add an awful lot of paths to its $PATH

[ryandesign (Ryan Carsten Schmidt)]

The port "mysql" was deleted, but the issue remains for "mysql3", "mysql4", "mysql5" and "mysql5-devel".

I'm not sure how much of a big deal this really is, though. Yes, there has been one occasion where I wanted to run a mysql4 server in parallel with my existing mysql5 server. But that was only to test one issue. I don't see this being an everyday desire. As for libraries, if a program is linked against some mysql 4.1.x library, the program should continue to work if you upgrade to a later mysql 4.1.x library. Same for the mysql 5.0.x and 5.1.x series. Now, if you linked against mysql 4.1 and are now upgrading to 5.0, then sure, you'll have to recompile your existing mysql software. Such major upgrades happen so infrequently, however, I'm not sure how much effort we should put into this.

[ryandesign (Ryan Carsten Schmidt)]

On the other hand, there have been some complaints about the allegedly convoluted directory layout the mysql5 port currently inflicts. Moving everything to $prefix/mysql$major (and, if you insist, $prefix/var/db/mysql$major) could greatly simplify the directory layout as well as allow simultaneous installation of different versions. Worth considering.

[yves@…]

The original issue, if I remember well, was having conflicts not between myself wanting two mysql versions but rather from multiple port dependencies requiring one and another.

For example, koffice requires mysql4 whie flow-tool requires mysql5.

On the other hand, it's been two years without much fuss.

[nox@…]

I think we should do another ticket for implementing something like the slot mechanism of Gentoo's Portage packet manager.

[(none)]

Milestone Port Enhancements deleted

[blb@…]

Can this be closed now that mysql5 installs files suffixed-by-5 in ${prefix}/bin and otherwise uses paths with mysql5 in them?

[ryandesign (Ryan Carsten Schmidt)]

No, the issue remains:

--->  Activating mysql4 @4.1.22_0
Error: Target org.macports.activate returned: Image error: /mp/libexec/mysqld is being used by the active mysql5 port.  Please deactivate this port first, or use 'port -f activate mysql4' to force the activation.

I do not foresee working on fixing this in the near future because I am working on other tasks, but I would like to keep this ticket open to document the fact that the issue remains. Even if mysql4 is old and might be deleted in 2010, the issue would remain relevant for a future mysql6 port.

[blb@…]

Ah, so there's at least one file which still conflicts; at least with MacPorts 1.8 you can simply use the conflicts key to note that the various mysql* ports do conflict (see #18794).

[ryandesign (Ryan Carsten Schmidt)]

Replying to blb@…:

with MacPorts 1.8 you can simply use the conflicts key

Done in r57246.

[chrstphrchvz (Christopher Chavez)]

In a4a1162eae29d8f8adb744a1b1f420569d5e03b2/macports-ports (master):

mysql4: delete EOL port

Port is not known to currently build; not obsoleting since it is almost
certainly no longer used. Remove all +mysql4 variants from dependents.

Closes: #4115
See: #43431
See: #58607