Add all mysql variants to ports that don't have them all

[mp@…]

In #39906, it was stated that the mysql5 port is deprecated and users should switch to mysql5{1,5,6} or other instead.

However, many packages depend on port:mysql5 which makes this transition impractical for many users. See #39940 for an example.

I think it would be necessary to switch from port: to file: or lib: dependencies, but I am not familiar enough with MacPorts to exactly tell what would be the right step to take.

[ryandesign (Ryan Carsten Schmidt)]

bin: or lib: dependencies are for situations where we want to allow software not installed by MacPorts to satisfy the dependency. We rarely want that.

path: dependencies are for situations where a number of ports install their files to the same locations and it is desired to allow any of them to satisfy the dependency. This is not applicable to the mysql situation because the mysql ports install their files to different locations. This was done deliberately so that the different mysql ports could be installed simultaneously.

What's needed is for each port that uses mysql5 to have variants added to allow the user to select among the mysql versions. The currently available versions are mysql5, mysql51, mysql55, mysql56, mariadb and percona. A single global ticket for this issue is not very useful because each individual port affected by this needs an individual fix, and the ports may have individual maintainers who need to implement or approve those changes.

The best way to help is to do the work yourself. Pick a port that depends on mysql5 and does not offer variants. Add variants for each of the mentioned versions of mysql. Test that they work and actually cause the software to be linked with the desired version of mysql. Then file a ticket for that port and attach your changes as a unified diff.

Until all mysql5-using ports are updated to have these variants, the default should probably still be the old mysql5 port.

[mp@…]

Thanks for your thorough explanation!

I was under the impression that variants add unnecessary complexity in case of packages (f. e. php5-mysql) where you just need the libmysqlclient*whatever and don't want to juggle/build so many variants because in fact you don't care about the version.

But if I get you right, this won't work anyway because of the different install locations of mysql51 et al.

Does that mean that for those packages, the base variant should depend on mysql5 and the version-specific variants replace that with a specific one?

Does that also imply that while it is possible to have f.e. mysql-51 and mysql-55 installed at the same time, depending-upon packages must be switched/deactivated because only one variant can be active - and the different mysql5{1,5,6} probably need to conflict because we cannot link against more than one version a time?

[ryandesign (Ryan Carsten Schmidt)]

Replying to mp@…:

I was under the impression that variants add unnecessary complexity in case of packages (f. e. php5-mysql) where you just need the libmysqlclient*whatever and don't want to juggle/build so many variants because in fact you don't care about the version.

But if I get you right, this won't work anyway because of the different install locations of mysql51 et al.

Variants are indeed an increase in complexity and should be avoided when possible, however when the goal is to offer the user a choice of library version to link with, variants are the only viable method.

php5-mysql is deprecated; use php53-mysql, php54-mysql, or php55-mysql; these have variants to let you choose the mysql version to use (although in this specific case, it is not necessary to use any mysql version, because the PHP team have written a replacement driver called mysqlnd which does the same thing, and that's the default variant for these ports).

Does that mean that for those packages, the base variant should depend on mysql5 and the version-specific variants replace that with a specific one?

I'm not sure I understand your terminology.

Port that use mysql should offer variants to let the user select which mysql to use. The variants should have the same names as the ports they depend on, so there would not be a variant called "mysql"; there would be variants "mysql5", "mysql51", etc. If a port currently has a "mysql" variant it would be deprecated and changed into a legacy compatibility variant for one year to help users transition to the new variant names. At this time, the default variant should be mysql5. Later, when all such ports have been updated to offer all these variants, we'll switch the default to the latest stable version, which is currently mysql56, and deprecate the old mysql5 variant. The method by which a port indicates its default variant(s) is via the default_variants keyword. See the neko portfile for a fairly simple example of how all this works.

Does that also imply that while it is possible to have f.e. mysql-51 and mysql-55 installed at the same time, depending-upon packages must be switched/deactivated because only one variant can be active

Yes. The ports mysql51, mysql55, mysql56, mariadb and percona can all be installed simultaneously, and it was deliberate decision (and a considerable effort on the maintainer's part) to make that possible. But only one variant of a port can be active at a time.

and the different mysql5{1,5,6} probably need to conflict because we cannot link against more than one version a time?

Yes, the mysql variants of a port need to conflict with one another.

[cooljeanius (Eric Gallager)]

Cc Me!

[patrick.sizun@…]

Cc Me!

[mojca (Mojca Miklavec)]

Cc Me!