py-yaml, py-dns and py-spf subports

Bradley Giesbrecht pixilla at macports.org
Tue Oct 4 20:34:30 PDT 2011


On Oct 4, 2011, at 7:33 PM, Ryan Schmidt wrote:

> On Oct 4, 2011, at 20:36, Bradley Giesbrecht wrote:
> 
>> Thanks. So using py-yaml for example, I changed:
>> python.versions     24 25 26 27
>> python.default_version 27
>> 
>> to:
>> python.versions     24 25 26 27
>> replaced_by         py24-yaml
> 
> Won't that cause *all* of the new ports and subports to be replaced by py24-yaml? Won't even py24-yaml then be replaced by py24-yaml? That doesn't sound right.
> 
> You only want py-yaml to be replaced by py24-yaml. And I believe that's exactly what the python portgroup does for you when you leave python.default_version at 24. So, just indicate the python versions. Don't modify the default version. Don't add a replaced_by line.

Your right. Now I have only python.versions.

>> Does replaced_by trigger an install of the replaced_by port?
>> Looking at "man portfile" suggest replaced_by does NOT trigger an install.
> 
> The manpage doesn't seem to say anything on the topic. I mean it mentions the replaced_by keyword but doesn't say anything about how it works.
> 
> When you put "replaced_by" in a portfile, and user has that port installed and tries to *upgrade* that port, MacPorts will instead deactivate the port and install the replacement port.
> 
> To get this to work smoothly you therefore need to additionally increase the version or revision of the replaced port (so that the port will appear in "port outdated" so that the user will be prompted to upgrade it), clear out the rest of its substance, and also add a block that prevents *installation* of the port in the first place (which replaced_by does nothing about). This is all described both in the guide and again in the PortfileRecipes wiki page (which I wrote without realizing we already had it in the guide).

Thanks, all three ports are also version upgrades.

>> One more question, I've seen other ports setting python.versions to 24 25 26 27.
>> Is this a good value for most cases? Is there a good method for determining what versions are good to use?
> 
> Allow the user to use as many python versions as possible, I'd say. If a particular module doesn't work with a particular python version, then don't offer that version. For example, some modules don't work with python 2.4 anymore, and many don't work with 3.x yet.

All three ports appear to work with python 2.4+ but not 3.x.

Thank you for the help.


Regards,
Bradley Giesbrecht (pixilla)






More information about the macports-dev mailing list