handle only subports install files

[Joshua Root]

On 2012-3-20 04:46 , Ryan Schmidt wrote:
> 
> On Mar 19, 2012, at 12:36, Joshua Root wrote:
> 
>> On 2012-3-20 04:32 , Bradley Giesbrecht wrote:
>>> Does anyone have an example of a better way to handle the primary port not installing files?
>>>
>>> Portfile:
>>> ...
>>> name mysql-connector-cpp
>>> if {$subport == $name} {
>>>   pre-fetch {
>>>       ui_msg "Stub port: Choose one of \
>>>           mysql5-connector-cpp, \
>>>           mysql55-connector-cpp, \
>>>           mariadb-connector-cpp, \
>>>           percona-connector-cpp.
>>>           "
>>>       return
>>>   }
>>> }
>>> ...
>>
>> "Don't do that?" There's no point creating a port that can't be installed.
> 
> No, this is a totally valid question that I've had too.
> 
> 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. 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.

> 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.

- Josh