It's been proposed on this list that we should rename MySQL ports e.g. mysql51 -> mysql-5.1; this would be to match the existing new ports mariadb-10.0 and mariadb-10.1. Consistency is good, especially within a particular type of software (e.g. MySQL in this case) but renaming MySQL ports is more problematic than renaming most ports, because MySQL ports are database servers and users may have databases and config files in their default version-specific directories which the user would manually have to move.
It's been proposed in #44995 that we should rename the GCC ports e.g. gcc49 -> gcc-4.9; this would be to match the existing Clang ports e.g. clang-3.4. Renaming GCC ports is problematic because MacPorts base contains code that assumes the GCC port names are gccXY, not gcc-X.Y, so any such rename would have to be simultaneous with a MacPorts base release. It seems like renaming ports just for this sake is a ***lot*** of work for I'm not sure how much benefit. And note that the GCC ports' naming convention far predates the Clang ports' naming convention in MacPorts. Prior to the appearance of the multiple Clang ports, MacPorts standard naming convention for versioned ports was to remove periods from the version number and add that to the end of the port name, e.g. to pick just a few examples: gcc49, php55, python27, ruby21, zmq22, sqlite3, textmate2, scala210, rpm54, mozjs24, libxml2, libgda5, kdelibs4, hdf5, gtk3, glib2, db60, apache2. Yes there have been exceptions like docbook-xml-5.0, and also the aberrantly named perl5.16. The problem with dashes in port names is that a dash is not a legal character in a variant name because it is confused with the syntax for disabling a variant, and often when there are multiple versions of a port, other ports will want to reference those multiple versions in corresponding variants. The problem with dots in port names is that so far "port lint" has declared the dot an illegal character in a variant name. This has led the perl5 port for example to adopt variant names like perl5_16 which I've always found a little confusing. It has been nice that under the original naming scheme, one could assume that in many cases the variant name matches the name of the dependency that will be added. If you want to use the python27 port, you use a port's +python27 variant, etc. The only disadvantage I see to the old naming scheme is ambiguity when a version number component reaches two digits, e.g. is the scala210 port version 2.1.0 or 2.10? (It's 2.10.) Is the ruby186 port version 1.8.6 or 1.86? (It's 1.8.6 -- perhaps this port should have been named ruby18 instead.) Leaving the dot in would remove the ambiguity, as demonstrated by the Perl ports, and "port lint" may be overly cautious in its prohibition of the dot in variant names. Someone should do some tests. Make variants with dots, like "mysql5.1", and see if they work correctly. Can you install the port? Can you upgrade the port? Can you uninstall the port? What if other variants are also selected? If everything works fine we can relax this lint restriction. I don't want to type extra punctuation at the command line to select variants, particularly the underscore because it requires the Shift key (on the US keyboard, anyway). And I don't want to take on massive port renaming efforts for the sake of the formatting of a version number. I don't plan to change the PHP ports and the almost 100 PHP modules and the dozen ports that have PHP variants, and I'll bet nobody wants to take on changing the Python ports and the almost 1000 Python modules and hundreds of ports with Python variants. Remember it would not only be the work of renaming all the ports, but also developing an upgrade strategy to help all the existing users of the ports under their current names. If dots in variant names work, we could consider whether going forward we want to recommend new ports that need to be versioned adopt the naming scheme fooX.Y instead of our previous standard fooXY. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
