subversion on 10.4

Ryan Schmidt ryandesign at macports.org
Thu Jun 11 14:34:38 PDT 2009


On Jun 11, 2009, at 07:27, Thomas De Contes wrote:

> Le 11 juin 09 à 06:54, Ryan Schmidt a écrit :
>
>> On Jun 10, 2009, at 17:10, Thomas De Contes wrote:
>>
>>> Le 10 juin 09 à 23:09, Ryan Schmidt a écrit :
>>>
>>>> On Jun 10, 2009, at 15:49, Thomas De Contes wrote:
>>>>
>>>>> Le 31 mai 09 à 07:28, Ryan Schmidt a écrit :
>>>>>
>>>>>>>> The workaround is to deactivate or uninstall 1.5.x and then  
>>>>>>>> clean and install 1.6.x.
>>>>>
>>>>> ... why not simply add the deactivate operation in portfile, to  
>>>>> upgrade ? :-)
>>>>>
>>>>> on top of that it is done anyway, but usually it is done after  
>>>>> building, not before,
>>>>
>>>> I'm sorry, that cannot be changed by a port.
>>>>
>>>> The order in which MacPorts base runs the phases is correct.
>>>>
>>>> What we need to do is make Subversion build a new version  
>>>> correctly even if an old version is active.
>>>
>>> but there is also a problem with cyrus-sasl2,
>>> isn't it the same ?
>>
>> I see the same symptom, yes. A similar solution would need to be  
>> applied to the cyrus-sasl2 port. If you can come up with a general  
>> change that should be made to MacPorts base that will not  
>> adversely affect too many other ports, we can certainly consider it.
>
> i'm not sure to understand the proposal
>
> i suggest that a port would be allowed to deactivate the old  
> version before build the new version, even if there is always a  
> better solution
> it would allow to have a workaroud, waiting to find the famous  
> better solution, since, anyway, if it is not done automatically,  
> users have to do the same manually .... so why prohibit it?
>
> of course, the default should not be changed, and you can disadvise  
> it (like for changing compiler, for example)

Allowing a port to deactivate the old version before building the new  
version, instead of after, would require new code in MacPorts base to  
allow that to happen. Someone would have to write this code. I would  
rather not expend developer time to do that when it is arguably a bug  
in the software, in this case a bug in cyrus-sasl2. We could either  
figure out how to fix cyrus-sasl2 so it can build properly even when  
an older version is already present, and then send that patch to the  
developers, or we could just report the problem to the developers and  
let them work out the correct fix. If you can help with either of  
these tasks I'm sure that would be appreciated.






More information about the macports-users mailing list