Thank you for the update but I see several issues that I would want to have resolved before committing it:
You've removed the postgresql90 variant and added a postgresql92 variant. This means that users who currently have the port installed with the postgresql90 variant who upgrade the port to this new version will no longer have postgresql support enabled. This is not ideal. I recommend you keep variants for many versions of postgresql: postgresql90, postgresql91, postgresql92, all marked as conflicting with one another. That way the user can choose the version they want.
Similarly with python. Users using the python26 or python31 variants, which you're removing in this update, will no longer have python support after upgrading. I recommend you retain the python26 and python31 variants, since there are no plans at this time to drop python26 or python31 support from MacPorts.
Similarly with mysql. Instead of changing the mysql variant from using mysql5 to using mysql55, you should add new variants mysql51 and mysql55 to support the mysql51 and mysql55 ports, marked as conflicting with the existing mysql variant, so that the user can choose which mysql they want. We are not yet at the point of recommending that users switch from the mysql5 port to the mysql51 or mysql55 ports because not all ports using mysql5 have provided variants for mysql51 and mysql55 yet.
For ports that require a Fortran compiler, or ports that link with such ports, the default version of gcc that we have selected at this time in MacPorts is gcc45. See wiki:PortfileRecipes#gcc. Therefore the gcc45 variant should not be removed from this port. We only recently changed the default gcc version from gcc44 to gcc45. See #33544. Discussions about changing it to an even newer version of gcc should be taken to the macports-dev mailing list.
After your patch, the configure arguments --with-cc=${configure.cc}, --with-cxx=${configure.cxx}, and --with-ld=${configure.cxx} are repeated three times in the portfile. This can be simplified.
Does the new cocoa variant really require a clang compiler? What happens if llvm-gcc or gcc are used? If clang really is required, would Apple's clang included with Xcode be sufficient? If so, that should be used instead of pulling in more dependencies. I'd also suggest the clang31 variant be removed and the clang dependency, if any, be added into the cocoa variant, and the cocoa variant could then declare conflicts with the gcc variants. We don't usually add variants for non-gcc compilers. (gcc compilers are special because they include Fortran compilers, so that's why we often see variants for those.)
