sudo port upgrade installed

[Ryan Schmidt]

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.