handle only subports install files

Ryan Schmidt ryandesign at macports.org
Mon Mar 19 11:34:29 PDT 2012


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.




More information about the macports-dev mailing list