Python 2.5 and py-crypto...

[Landon Fuller]

On Feb 22, 2007, at 3:15 AM, Weissmann Markus wrote:

> On 22.02.2007, at 03:54, Randall Wood wrote:
>
>> On 21 Feb 2007, at 20:43, Landon Fuller wrote:
>>
>>> On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
>>>
>>>> Hi Douglas,
>>>>
>>>> the soon-to-be-released version 1.4 of port will come with a  
>>>> python 2.5 "port group". This will allow us to quickly produce  
>>>> all the python vastness for python 2.5, too.
>>>> This might be a chance for newcomers to start coding Portfiles:  
>>>> Basically you will have to replace the "GroupCode" line and the  
>>>> name from the python 2.4 module Portfile to get a Python 2.5  
>>>> one. People with the release candidate of 1.4 installed can  
>>>> already hack away here (just don't put that code into the  
>>>> repository yet - as long as 1.4 is not released)
>>>
>>> I'm nonplussed by the massive code duplication that will occur  
>>> for py25 portfiles -- these will almost invariably be direct  
>>> copies of the py24 portfiles.
>>> I'm not sure of the best solution -- perhaps python portgroup can  
>>> either point to 24 or 25?
>>>
>> I'm  nonplussed (even upset) about broken python applications  
>> because suddenly some py-* ports (read py-wxPython (there may be  
>> others--I just don't know)) depend on python25 while other py-*  
>> ports depend on python24.
>>
>> The Fink developers hashed out this problem a few years back with  
>> perl version 5.6 / 5.8 problems and concluded that the only road  
>> forward was package duplication. I say duplicate the ports!
>>
>> Although perhaps if we could create a Portfile.in type or style of  
>> port that really generates multiple installable ports, we'd have  
>> an easy solution...
>>
>
> The problem I see here is, that there is code that runs with 2.5  
> but not with 2.4 (and vice versa). Therefore we would at least need  
> a mechanism for also allowing the "cheap" duplicate ports (for 2.4  
> and 2.5) as there will be modules that work with 2.4 in version A  
> and only with 2.5 with version B.
> Could we perhaps somehow specify two port definitions in one  
> Portfile? Or find a good mechanism to include the common parts of  
> two Portfiles from a shared third file? Thoughts?

We could adapt the "include" mechanism such that one could include  
other Ports (or meta ports) in the index. "Meta ports" would require  
some analogue to PortSystem that informed the indexer that it should  
not index that specific port.

-landonf