Add concurrent for multiple flavor installation. This requires the concurrent fixes for devel/dulwich in bug 236428 to be useful.
Created attachment 203006 [details] add concurrent, bump revision
Created attachment 204077 [details] add concurrent and suffix, bump revision Adjusted patch; per r500253, apparently PYTHON_PKGNAMESUFFIX isn't so deprecated as claimed. Switch over to suffixing rather than prefixing for the flavors, on the theory that as primarily a program rather than a library, putting the program name first in the package name makes for a better user experience.
-0 on switching from PKGNAMEPREFIX to PKGNAMESUFFIX. I understand (and agree with) the motivation described in comment 2, but there's no real established trend or consistency in existing ports to do this, leaving the change as an exception to existing expectations, which IMO negatively impacts UX and is a POLA violation (contrary to the stated goal). This is a broader issue impacting python packages (like django ports as well) with points to be made on both sides about how things should be ultimately grouped. I believe at this point though, we should lean towards consistency until we have a good schema defined for how we might want to do things across the board Would you mind switching this back to using PKGNAMEPREFIX?
Sorry for the slow response; been a busy couple weeks. It can certainly it can be argued both ways. And it does has a ports-policies bent. It wouldn't be a lone outlier; there are a good dozenish ports already that follow a similar pattern, for presumptively similar reasons. e.g., devel/pylint*, devel/drpython, mail/svnmailer, and others. (also noticed in scanning are textproc/py2html and databases/zodb3 which do some gymnastics to arrive at the PYTHON_PKGNAMESUFFIX value, but without using that name; they probably deserve a little tweaking) From the maintainer side, I do think it's a decidedly better choice. It _is_ a separate issue from concurrent-enabling to be sure. I just took the chance to get 'em both in in one revision bump, and also to change it around while the port is still relatively young and has had less chance to get itself known under the old naming. But I do agree that it's a port-team-policy sort of choices, at least as much as a maintainer's. I haven't managed to find anything specifically addressing it or en/discouraging one way or another in the porter's handbook. I do see a mention of USE_PYTHON=optsuffix, though Uses/python.mk has a deprecation warning on using it; probably should be mentioned there... So, I'd'ruther suffix it. But, if that's the way ports is decided to be, or you think it's undecided but currently more consistently prefixed, that's reasonable enough.
(In reply to fullermd from comment #4) We'd prefer PYTHON_PKGNAMEPREFIX until such time as we have a clear class/category requirements for when suffixing is the better option, which we don't have yet. The majority of ports, independent to whether they just present/install single command line utilities use prefixing (like this port), and that's what users expect and see installed in general, and its not immediately clear to them why something might be suffixed/prefixed
OBE: see bug 238949, which rolls the concurrent-ization together with new upstream release, and leaves the suffix.