sudo port upgrade installed

[Frank J. R. Hanstick]

Hello,
	Interesting that one might want to use a port during the process of  
upgrading.  Does MacPorts check to see if the module is in use before  
deactivating and reactivating?  If not, what happens if the links are  
severed during usage?  It MacPorts does check "in use", does it wait  
until usage is over before deactivating and reactivating?  I think  
preventing usage during an upgrade process would be far superior to  
using and having links severed during usage..
Frank

On Nov 29, 2008, at 11:48 AM, Ryan Schmidt wrote:

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