digikam: Add variant for external mysql database; rename variant for internal mysql database; update mysql dependency

[sk-public@…]

Support for external mysql databases has been disabled by default since digikam 4.4 (or thereabouts). This patch to the 4.8.0 portfile:

1. Adds a variant, mysql_external to enable support for external mysql databases.
2. Renames the current mysql_check variant to mysql_internal, to reflect what that option actually does -- enable the internal mysql database.
3. Updates the mysql dependency for the internal mysql database to version 5.6.

[sk-public@…]

Patch to digikam 4.8.0 for external mysql variant, rename current mysql_check

[ryandesign (Ryan Carsten Schmidt)]

What does it mean, "internal" and "external" MySQL databases?

Changing the dependency to "path:bin/mysql_config:mysql56" is not correct because the mysql56 port does not provide the file /opt/local/bin/mysql_config. Instead, you would just write "port:mysql56". But typically there should be variants allowing the user to choose which MySQL implementation they want: mysql55, mysql56, mariadb, mariadb-10.0, mariadb-10.1 or percona. The naming of these variants, especially the mariadb ones, has not yet been standardized. In each variant you will need to inform the configuration system somehow where that MySQL is located.

[sk-public@…]

The mysql_external variant restores support for storing the digikam database in a MySQL server, using the Qmysql3 database plugin. This capability was included by default until 4.4 (so this variant became necessary when the macports version jumped from 4.0 -> 4.8).

The mysql_internal (the current "mysql_check") variant causes digikam to use MySQL internally instead of sqlite. I've never tried it - I'm not sure what advantage it provides. Building with this option (ENABLE_INTERNALMYSQL) requires access to the mysqld binary at build time. I changed the name only to avoid confusion with the mysql_external variant, and the default mysql version to avoid issues when both are compiled.

bin/mysql_config is a symlink created by port select --set mysql mysqlxx. It looks like the mysql_check variant was written to incorporate whatever version of mysql is installed, as opposed to specifying different options for each version. It's probably not required for mysql_external though -- I'll try removing it when I get a chance.

[sk-public@…]

Includes variants for mysql51, 55, 56, and mariadb external databases, and renames mysql_check to mysql_internal.

[sk-public@…]

I uploaded digikam-mysql-2015-04-14.diff​, with mysql51_external, mysql55_external, mysql56_external, and mariadb_external variants, all of which enable support for external MySQL databases (as opposed to the default builtin SQLite). I've tested by building with the mysql56_external variant.

The patch also renames the mysql_check variant to mysql_internal, which better describes what that variant does (allow use of an internal MySQL database), and distinguishes it from the _external variants. However, I don't use that capability. I'm not even sure why it's necessary -- I built it by accident because I thought it might re-enable support for external MySQL databases. It doesn't. I think it should be renamed to mysql_internal to prevent that confusion. I did changed it to look for bin/mysql_config instead of mysql_config5. The former is created by port select --set mysql mysql5_, I don't think anything provides mysql_config5.

[ryandesign (Ryan Carsten Schmidt)]

The obsolete mysql5 port provides mysql_config5.

Ports should not depend on things created by port select. That results in non-reproducible builds.