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.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
