Ports with a mysql4 or mysql5 variants and/or dependencies should switch to using mysql56 or possibly mariadb.

[pixilla (Bradley Giesbrecht)]

The following ports have variants and/or dependencies on mysql5:

==== Ports which require maintainer approval ====
 - apr-util (geeklair.net:dluke):
 - drupal5 (acm.org:c_dantonio):
 - drupal6 (acm.org:c_dantonio):
 - libdbi-drivers (umich.edu:mta):
 - libgda (landonf):
 - lighttpd (ryandesign):
 - lighttpd-devel (ryandesign):
 - mediatomb (gmail.com:yattenator):
 - mysql-connector-odbc (pixilla):
 - mysql5 (ryandesign,pixilla):
 - mysql55-lib_mysqludf_json (pixilla):
 - mysqlxx (genetikayos.com:kayos):
 - php (ryandesign):
 - php4 (ryandesign):
 - php52 (ryandesign):
 - qore-mysql-module (davidnichols):
 - radlib (mbclark):
 - rb-mysql (freebsd.org:roberto):
 - restund (db.org:aeh):
 - vpopmail (yahoo.com:compconsultant):
 - wikkawiki (wikkawiki.org:brian):

==== Ports with openmaintainer ====
 - dovecot (jberry,openmaintainer):
 - dovecot2 (pixilla,openmaintainer):
 - dspam (pixilla,openmaintainer):
 - libgda4 (devans,openmaintainer):
 - libgda5 (jwa,devans,openmaintainer):
 - mnogosearch (gmail.com:dbraband,openmaintainer):
 - mysql55-connector-cpp (pixilla,openmaintainer):
 - neko (ryandesign,openmaintainer):
 - ocaml-mysql (mww,openmaintainer):
 - postfix (jmr,openmaintainer):
 - pure-ftpd (pixilla,openmaintainer):
 - qt3-mac (blair,openmaintainer):
 - qt4-mac-mysql55-plugin (michaelld,pixilla,openmaintainer):
 - redland (pixilla,openmaintainer):
 - soci (rmh.de:g.lorenz,openmaintainer):
 - zabbix2 (eborisch,openmaintainer):

==== Ports with nomaintainer ====
 - bugzilla (nomaintainer):
 - exim (nomaintainer):
 - flow-tools (nomaintainer):
 - freeradius (nomaintainer):
 - gdal (nomaintainer):
 - grass (nomaintainer):
 - hydra (nomaintainer):
 - nagios-plugins (nomaintainer):
 - p5-dbd-mysql (nomaintainer): See #44484. 
 - pennmush (nomaintainer):
 - php5-mysql (nomaintainer):
 - py-oursql (nomaintainer):
 - rb19-mysql (nomaintainer):
 - snort (nomaintainer):
 - sphinx (nomaintainer):
 - vtk-devel (nomaintainer):
 - zabbix (nomaintainer):

Ports where mysql5 has been removed:

 - akonadi
 - amarok-devel (port obsolete)
 - dbslayer
 - libzdb-mysql55
 - proftpd (nomaintainer):
 - py-mysql

[danielluke (Daniel J. Luke)]

apr-util has other mysql variants - are we removing mysql5 variants now? Is there a standard way we're deprecating them?

[pixilla (Bradley Giesbrecht)]

Replying to dluke@…:

apr-util has other mysql variants - are we removing mysql5 variants now? Is there a standard way we're deprecating them?

One goal should be to have mysql5 replaced_by mysql51 so for ports that cannot use a more modern mysql they would have their dependencies changed from mysql5 to mysql51.

That said, mysql51 is the same version (5.1.72) as mysql5 and pretty ancient. I believe we should settle on a MacPorts "default" mysql port and encourage subports and/or variants when other mysql versions are desired. I appears to me that many distros are choosing mariadb as their default. If we choose mariadb as our default perhaps we should rename mariadb to mariadb55 before we modify all these mysql5 dependent ports. I would am fine with and might prefer mariadb (the founder of mysql is behind mariadb) as the "default" MacPorts mysql port.

A standard way for variants might be:

# Removing mysql5 variant
# variant mysql5 {}
variant mysql51 {...}
variant mysql55 {...}
variant mysql56 {...}
variant mariadb55 {...}
variant percona56 {...}
if {[variant_isset mysql5]} {

    default_variants.append    mariadb55
}

[ryandesign (Ryan Carsten Schmidt)]

Replying to dluke@…:

apr-util has other mysql variants - are we removing mysql5 variants now? Is there a standard way we're deprecating them?

• mysql56 variants should be added where missing.
• mariadb and percona ports and variants should be renamed to be versioned.
• mysql5 variants should be auto-upgraded to mysql51 variants ("variant mysql5 requires mysql51 description {Legacy compatibility variant} {}"), this way users using mysql5 databases only need to move their database to a different directory to be able to continue using mysql51 (or, if just checking if the variant is set, without defining the variant, correctly upgrades users in that manner, then that's fine)
• mysql56 (or mariadb (or mariadb55 if we rename it)) should be the default variant (which would apply for new installations, not upgrades)
  • Alternately we could auto-upgrade mysql5 to mysql56 or mariadb (or mariadb55 if we rename it), but then the user might have to do additional steps other than just moving the files (e.g. running upgrade scripts). The whole reason why we have versioned MySQL (and PostgreSQL and BerkeleyDB) ports is so that users can decide when to upgrade to newer versions that require such extra steps.

[ryandesign (Ryan Carsten Schmidt)]

Replying to pixilla@…:

I appears to me that many distros are choosing mariadb as their default.

MariaDB (whatever the variant for the latest version thereof is called) would be my first choice for default.

[dbraband@…]

Cc Me!

[dbraband@…]

Cc Me!

[dbraband@…]

Cc Me!

[NicosPavlov]

akonadi done in r119433.

[ctreleaven (Craig Treleaven)]

Cc Me!

[cooljeanius (Eric Gallager)]

Cc Me!

[mkae (Marko Käning)]

Cc Me!

[patrick.sizun@…]

Cc Me!

[petrrr]

Cc Me!

[mojca (Mojca Miklavec)]

Cc Me!

[petrrr]

Vincent, I add you here to CC as maintainer of gdal.

[NicosPavlov]

Moving amarok-devel which is obsolete (amarok has default variant on mariadb55).

[macports@…]

Cc Me!

[pokui@…]

Replying to hum@…:

#47671 fixes exim - any reason to keep the mysql4 variant in the exim port?

[pixilla (Bradley Giesbrecht)]

Replying to pokui@…:

Replying to hum@…:

#47671 fixes exim - any reason to keep the mysql4 variant in the exim port?

No, mysql4 variants and dependencies should be removed. I updated the ticket description. Thank you for asking.

[mojca (Mojca Miklavec)]

Can someone please provide an example of how the dependencies and variants should be implemented in an ideal case?

How exactly should we modify ports that depend on mysql5? Should we support automated migration? (I see that monarch is missing in the list of ports.)

[BjarneDMat]

Cc Me!

[pmetzger (Perry E. Metzger)]

Ryan, would you be able to provide an example (as per Mojca's question above)? Then volunteers could go through and fix all the related ports.

[ryandesign (Ryan Carsten Schmidt)]

It would be great if the names of the variants were consistent in all ports. Until the introduction of the mariadb-10.0 port, that was easy: we just made the variant name the same as the name of the port that the variant depended on (e.g. "mysql5" or "mysql57"). But we can't name a variant "mariadb-10.0" because "-" and "+" are illegal characters in variant names, because MacPorts uses "-" and "+" to indicate disabling and enabling variants, respectively.

"." was an illegal character in variant names too, but we couldn't figure out a reason why, so as of MacPorts 2.4.4 that's no longer illegal. See #46807.

So we need to make a decision on what the variant names should be. For ports like mariadb-10.0, the obvious variant name choices are "mariadb10.0" and "mariadb100". The former avoids ambiguity and is probably the better choice. Avoiding ambiguity is probably why Bradley chose to name the port "mariadb-10.0" instead of "mariadb100". I think using the dot in the variant name is what we wanted to do awhile back, but couldn't do until the unnecessary variant name restriction in base was relaxed.

We might also ask whether anything should be done about the older ports mariadb, mysql51, mysql55, mysql56, mysql57. Should they be renamed to mariadb-5.5, mysql-5.1, mysql-5.5, mysql-5.6, mysql-5.7, or left alone? Should variants that use those ports be renamed to mariadb5.5, mysql5.1, mysql5.5, mysql5.6, mysql5.7, or left alone? It would be good to make that decision before adding variants to a lot of ports, so that we don't have to rename them all again later. Renaming them would be good for consistency, but might be a lot of work, especially if we want to add automatic upgrade paths that keep the old variant names around for awhile.

Existing variants for other versioned ports—like gcc, clang, php, python, perl, ruby—don't use a dot in the variant name. But none of them have reached a major version number of 10 or greater yet. gcc is close, since they're developing version 9 now, but back in version 5 they changed their version numbering scheme so that the major version was only the first number of the version, not the first two numbers. So we used to have variants gcc48 and gcc49, but now we have variants gcc5 and gcc6. Even when gcc reaches version 10, we'll just name the variant gcc10; no need for a dot. PostgreSQL made the same version numbering change when they release version 10. MySQL has skipped from version 5.7 to version 8; not sure what their versioning strategy is going forward. Percona seems to express their version number is a modifier of the MySQL version number, so I don't know if we should be offering separate Percona ports for each MySQL version.

Once we decide variant names, we can propose code that creates those variants. So far, most of the mysql variants I've seen have been manually created. This can become inconvenient when each variant has to duplicate similar code that varies only by version number or include paths. Python variants are often created programmatically, using a loop, so that the code unique to the port that tells the build system where MySQL is doesn't have to be duplicated. We can probably adapt the Python-variant-generating code for MySQL.

[ryandesign (Ryan Carsten Schmidt)]

example of proposed general purpose mysql/postgresql/sqlite variant generating code

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

We can probably adapt the Python-variant-generating code for MySQL.

But we would probably have to make such code accommodate multiple database systems—at least MySQL, PostgreSQL and SQLite. Consider the bacula port, which has variants client_only mysql51 mysql55 postgresql83 postgresql84 sqlite3, all of which conflict with one another. (The client_only variant is probably evidence of a missed opportunity to offer separate client and server subports.)

See bacula.diff​ for proposed code that accommodates this.

[ryandesign (Ryan Carsten Schmidt)]

a simpler example of the proposed db-variant-generation code

[chrstphrchvz (Christopher Chavez)]

proftpd is nomaintainer: #45847