Thanks to replies from Bob Vickers, Dr Tom, and Steve Tom, et al, who
all confirmed/concurred with me that the Tru64 patch process does take
extraordinarily long and the process is painful for others. (I was
hoping it was just me and would get a quick fix response :-).)
Dr Tom's response is below since it was quite informative on the process.
_Mike
Welcome to the perverse world of "dupatch". I suspect (but I'd have to
instrument the "dupatch" shell script to be sure) that a lot of the time
when it seems to be "just sitting there" is spent in dependency analysis.
It is, unfortunately, a tool that does NOT scale well in the face of many
patches, and it's paranoid (because a bad patch can break a system, but
also because the patch kitting process is unreliable and the people who
wrote "dupatch" didn't seem to know how to get things right themselves --
oh, is my experience with the tool and developers showing?). You are of
course right, it should NOT take all the time it takes to apply patches
to the product, and the tool should be FAR more informative about what
it is doing, especially if it's doing something that takes a long time.
And the critical sections that take a long time should be rewritten to
use compiled code, instead of shell scripting (the original implementation
apparently assumed you could not deliver much in the way of tooling as a
part of the patch kit, so they tried to do EVERYTHING in shell scripting,
instead of identifying the complex and slow parts and implementing them
with simple fast helpers).
But trust me, it's NEVER going to get better. And "management" just can
not understand why customers are frustrated with the patch process and
aren't willing to apply new patches in a "timely manner".
Mike Broderick wrote:
> Is it normal for Tru64 patches to take an extraordinary amount of
> time? Do others see this too?
>
> I've always thought patching Tru64 took too long but was usually
> installing large patch kits (hundreds of patches) so didn't think much
> of it. This past week I had to install PK#5 on 5.1a plus a single
> file customer specific patch (fix ps output wrt brackets). The CSP
> which replaces just one file and rebuilds the kernel took as long as
> 27 minutes (not including the reboot) on an ES40 w/ four 500Mhz
> processors and 10GB mem. On other DS20s two CPUs and 4-8GM mem it
> took no less than 15 minutes. I realize that the patch process may
> not take advantage of multiple CPUs, but 27 minutes to install a
> single file is ridiculous.
> There are parts where the process just sits there for 5 minutes or
> more with no output and I can't figure out what it's doing at that
> point. I'm in single user mode so I can't see what's going on from
> another login. Is it possible that it's waiting for something that
> isn't there so it eventually times out after waiting a few minutes (a
> guess)? I'm hoping there's some explanation that I could work around
> to speed the process up.
>
>
> _Mike
>
>
Received on Wed Nov 05 2003 - 22:56:59 NZDT