sudo port upgrade installed

[Ryan Schmidt]

On Nov 29, 2008, at 12:44, Joshua Root wrote:

> Frank Hanstick wrote:
>
>>     I did the deactivate and independent install which worked;  
>> but, the
>> question remains as to why was cyrus-sasl reactivated before  
>> upgrading
>> when deactivated before hand.
>>     What I am referring to as a script is the procedure by which
>> MacPorts upgrades ports which may not literally be a script; but, a
>> script in the sense that a strict set of procedural steps are  
>> followed.
>>     I notice in the upgrading process, that deactivation of an  
>> installed
>> module occurs immediately after the building.  Could the  
>> deactivation be
>> changed to the point where the needed upgrade is made, which I  
>> assume is
>> before the build, and reactivated afterwards whether or not an  
>> upgraded
>> installation occurred?  This seems like a simple change to the
>> procedural steps by someone who knows the insides of MacPorts.
>
> A change along those lines is probably possible, but I would not
> characterise it as simple.

To upgrade a port, MacPorts currently runs the phases in this order:

fetch
checksum
extract
patch
configure
build
destroot
install
deactivate
activate
clean

I may have missed a phase or two but that's basically it. MacPorts  
gets, verifies and compiles the new version of the software, stages  
it into the destroot, copies it into the software directory, and just  
before making the hardlinks in ${prefix} to activate it, it first  
removes the old hardlinks in ${prefix} belonging to the old version.  
The reason for this order is so that the old version remains  
available to any other processes on your machine for as long as  
possible.

However, cyrus-sasl2 is in the small minority of software that does  
not build correctly when another version of cyrus-sasl2 is activated.  
This is a bug in cyrus-sasl2 which the authors of that software have  
not fixed, so all we can do for now is offer workarounds.

To fix it in MacPorts base would require changing the order of the  
phases so that deactivate comes before configure. This would mean  
that for the entire duration of configure, build, destroot and  
install, the old version of the software would not be available.

This might be ok for cyrus-sasl2 which probably builds pretty quickly  
even on slow machines. But consider the larger ports. If I want to  
upgrade gcc43 or ghc on my Power Mac, it will take about a day to  
compile. Now it's possible that some time during that day I will also  
want to make use of gcc43 or ghc. With your proposed change, I would  
no longer be able to do that because it would have already been  
deactivated.

A better solution is to work with the authors of cyrus-sasl2 to get  
their software to compile correctly even if another version is  
already available on the system.