On 01.10.2014 09:39 pm, Sean Farley wrote: > Lawrence Velázquez writes: > >> On Sep 16, 2014, at 5:22 PM, Ryan Schmidt <[email protected]> wrote: >> >>> 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. >> Consistency is good, but I'd argue not especially critical. If migrating a >> particular port or set of ports would be too much work, it would not be the >> end of the world if we left it/them. >> >> Consistency of variant names is probably more important than consistency of >> port names, since it affects variant inheritance. > This is an important point, thanks.
Variant names, however, are easily changed with help of TCL magic. This is not as easy for whole ports. (Ex.: keeping the old variant around, which "only" activates the new variant if it itself is activated, to ensure a smooth upgrade path. Much like the no_foo => foo variant changes.) >>> 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. >> True, but we already have tons of ports with hyphens in their names. It >> seems odd to me to use hyphens in some places (e.g., `py34-requests`) but >> avoid them in others (`gcc49`). > Very much agreed. port install (and other subroutines) already recognize "gsed-bar+foo-baz" as one port name, so the problem is (currently) not a problem anymore. IIRC current base requires variants to be delimited by a white space from the port name. A version number is already delimited by "@" (with or without white space after port name, so "@" is indeed an invalid port name character), with variants following the version number (which naturally may contain dots, but not '-' or '+'?) >> Matching variants and dependencies is certainly nice, but I don't think we >> should get hung up on it, since the dependencies are added automatically. I >> personally would be entirely fine with `+gcc4.9` pulling in `gcc-4.9`, and I >> think the hyphenated port names look cleaner. This is entirely subjective, >> of course. This issue could be fixed by requiring white spaces after/before each individual variant. But we probably don't want to go there. >>> The only disadvantage I see to the old naming scheme is ambiguity [...] >> I haven't done any tests, but I'd much prefer adding the periods, if >> possible. > I agree with this, too. Yes. Ambiguity should be avoided at all costs. Mihai _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
