sudo port upgrade installed

[Frank J. R. Hanstick]

Hello,
	Tell me the point when the server will be shut down using "sudo port  
upgrade installed" in the current state so that I do not have  
something important running when the transition between switching  
modules occurs?
	This does not sound like running "sudo port upgrade installed" when  
you do not know when the shut down would be required.  Is "sudo port  
unload mysql5", "sudo port deactivate mysql5", "sudo port activate  
mysql5", and "sudo port load mysql5" done with the "sudo port upgrade  
mysql5" or do each of the steps need to be individually done?  If it  
is being done via the latter command, how can you be sure the shut  
down will occur during the specified down time?
	I will admit that there are scenarios where one set of procedures  
will at times seem better than other sets of procedures; but, both  
have costs that are to be decided on when implementing.  The cost of  
not deactivating until the last instant is the possibility that the  
deactivation will unceremoniously bring something in the system or  
the system itself to a grinding halt which at best creates an  
unscheduled wasted downtime or at worse does some real damage that  
could have been avoided whereas the other cost is possible wasted  
downtime for a failed upgrade.  Most complain about the latter until  
the former occurs.  It all depends on what one can live with.
	Like I said, I do the upgrades when I do not have anything related  
running and I do it in this manner because I have experienced the  
former more times than I care to think about.  Maybe I am just lucky  
in that I always have other unrelated things that need doing during  
the upgrade period.
	As a side point, another question is why cyrus-sasl2 was  
transitioned from the deactivated state to the activated state by  
"sudo port upgrade installed" before testing for upgrading?  I would  
guess that a module dependent on cyrus-sasl2 had detected that cyrus- 
sasl2 was deactivated and activated it before determining that the  
dependency was to be upgraded.  Should there be a dependency check  
for upgrading as well as installing so that deactivation of a  
dependency does not effect the dependent module?
Frank

On Nov 29, 2008, at 10:16 PM, Ryan Schmidt wrote:

>
> On Nov 29, 2008, at 23:40, Frank J. R. Hanstick wrote:
>
>> On Nov 29, 2008, at 6:53 PM, Neil wrote:
>>
>>> On 29 Nov 2008, at 19:43, Frank J. R. Hanstick wrote:
>>>
>>>> On Nov 29, 2008, at 2:46 PM, Neil wrote:
>>>>
>>>>> On 29 Nov 2008, at 16:46, Frank J. R. Hanstick wrote:
>>>>>
>>>>>> I think preventing usage during an upgrade process would be  
>>>>>> far superior to using and having links severed during usage..
>>>>>
>>>>> Okay, so I'm upgrading gcc43, going from 4.3.1 to 4.3.2  
>>>>> (current).  It's going to take 2 hours say.  You find it  
>>>>> superior that MacPorts should (somehow) stop me from using gcc  
>>>>> 4.3.1 to perhaps write a couple hello-world sized test cases  
>>>>> while it's compiling gcc 4.3.2 instead of just compiling 4.3.2  
>>>>> elsewhere, and then swapping them out when it's done?
>>>>>
>>>>> Kindly permit me to draw you an analogy:  You want to buy a new  
>>>>> car.  The search for a new car will take 3 weeks.  You find it  
>>>>> superior that I take away your current car while you're  
>>>>> shopping for the new car, instead of letting you use your  
>>>>> current car up until you find a new car, and then swapping them?
>>>>>
>>>> 	And I will give you an even better example.  Your compilation  
>>>> is 30 seconds from finished and the links to gcc are lost, then  
>>>> what?  You prefer to have your compilation crash?  Your analogy  
>>>> is MBE.  The car you have is not linked to one being upgraded.   
>>>> It would be like your current car suddenly quitting while your  
>>>> are driving it in the middle of the freeway because the new  
>>>> model is now ready.  Get a better analogy.
>>>
>>> If your compilation is going to take that long, then it wouldn't  
>>> finish under either scenario; so there is nothing to lose.  But  
>>> if your compilation is 30 seconds shorter, then under your  
>>> scenario is fails, and under the current scenario it doesn't.
>>
>> 	How does not starting anything until the upgrade is finished fail  
>> in any manner?  I do not call waiting for something to finish  
>> before starting something else a failure.  Personally, when I  
>> upgrade, especially when the upgrade is an all encompassing  
>> upgrade, I do not have anything running that could be effected by  
>> any module being upgraded.  The only time I run multiple processes  
>> is when I know the processes are not going to interact in some  
>> unpredictable way (unless I am debugging interconnecting processes  
>> in which case I am quite prepared for failures).  One process  
>> randomly linking and unlinking modules used by other processes  
>> does not make for good predictability.
>> 	Which leads to a second point.  It does not even have to be a gcc  
>> or any other long period upgrade,  It could just as well be from a  
>> library reference or some other required linkage that could be  
>> lost at the wrong moment.  This is true even from very short time  
>> spans between deactivation and activation since everything is  
>> running asynchronously.  Trying to simultaneously run and upgrade  
>> modules that interlink with each other (either running or being  
>> upgraded) is just asking for trouble.
>
> I've been reading the discussion up to this point, just listening  
> to what's being said.
>
> I wanted to point out another useful scenario that's possible  
> because of the way MacPorts is currently implemented. Imagine you  
> have a server that runs MySQL or something. You want to upgrade to  
> the new version of MySQL, and you want to do so after hours when  
> the downtime will affect fewer people. But MySQL takes a long time  
> to compile. It is nice to be able to type "sudo port install mysql5  
> +server" at some point before the scheduled downtime (possibly  
> before you have even scheduled the downtime) to build the new  
> version. Then, at the scheduled downtime, all you have to do is  
> "sudo port unload mysql5", "sudo port deactivate mysql5", "sudo  
> port activate mysql5 @<new_version>", "sudo port load mysql5" (and  
> probably run mysql_upgrade5).
>
> With the proposed changes of deactivating the old version before  
> beginning to configure, the server would have to be shut down  
> during the MySQL build. In the best case, that means your scheduled  
> downtime has to be much longer, long enough to accommodate the  
> build. In a worse case, the compilation fails at some point and you  
> have to report a bug and continue using the old version of MySQL,  
> and you've taken the server offline for nothing.
>