On Mar 19, 2012, at 13:29, Joshua Root wrote: > On 2012-3-20 04:46 , Ryan Schmidt wrote: >> >> The python portgroup has this problem with its py-foo ports; they serve no >> purpose; the user should not install them; the user should install the >> specific versioned subport. The python portgroup solves this by making >> py-foo a stub port that installs just a readme, and declares a dependency on >> one of the subports. > > They do serve two purposes, in fact. One is to preserve the upgrade path > for the old python24 ports via replaced_by.
Sure. But for new ports like Bradley's we can ignore that part. > The other is to let users > ask for the module installed for some default/recommended python version > -- this part will start working once all the python24 ports are unified > and the dependencies updated. Yes, and that's valuable... but sometimes, like in Bradley's mysql-connector-cpp, or in my VillainousStyle, there might not be a particular port that it would be appropriate to call the default. >> Same with the perl5 portgroup, and the new unified php portgroup, and with >> ports like VillainousStyle. >> >> It might be nice if MacPorts could automatically tell the user not to >> install undeclared subports. That's the reason why I'm trying to declare >> every usable subport, i.e. why I make changes like this: >> >> https://trac.macports.org/changeset/90954 > > That's just silly. There's nothing inherently special about the "top > level" port except that it doesn't have an explicit subport block, which > is so you can keep writing ports the way you always could before there > were subports. I don't think there's anything silly about wanting to group multiple subports together in a single Portfile, yet not want the top-level port name to be an installable port; I gave several examples. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
