In the past EMC have not so much “issued” cumulative patch clusters, but let them trickle out on an as-needs basis.
With the 7.5.1 cumulative patch cluster, this appears to be following the same general scenario – there’s certainly nothing in PowerLink’s download section (as of this morning) that indicates anything different.
However, this morning I finally got around to installing the cumulative patch cluster for my primary lab machine, and noticed something very odd. You see, when I’d been given the details for downloading the cumulative patch cluster (as part of a support case), I’d set the download running and kept working on other things, so this is the first time I’ve actually gone to look at the files.
When I decompressed the Linux 64-bit Intel package though, I thought maybe I’d uncompressed the wrong thing – it was a bunch of RPMs. If you’ve got any familiarity with NetWorker cumulative patch clusters, you know they’re usually done as a bunch of standalone binaries. Indeed, the couple of pages of notes I got over the patch cluster indicated just this.
However, the story is very different. The cumulative patch clusters I downloaded as part of my support case for 7.5.1 are actually completely new replacement distributions for 7.5.1.
Here are the file sizes – something I should have looked at earlier, but didn’t think to:
[root@nox 7.5.1.2-Cumulative]# du -hs * 235M nw75sp1_aix.tar.gz 148M nw75sp1_hpux11_64.tar.gz 97M nw75sp1_hpux11_ia64.tar.gz 63M nw75sp1_linux_ia64.tar.gz 15M nw75sp1_linux_ppc64.tar.gz 180M nw75sp1_linux_x86_64.tar.gz 186M nw75sp1_linux_x86.tar.gz 228M nw75sp1_solaris_64.tar.gz 62M nw75sp1_solaris_amd64.tar.gz 24M nw75sp1_solaris_x86.tar.gz 79M nw75sp1_tru64.tar.gz 27M nw75sp1_win_ia64.zip 160M nw75sp1_win_x64.zip 155M nw75sp1_win_x86.zip
As you can see, those sizes alone are indicative of distributions. [edit – 2009-06-26 had said “…of patches” by mistake.]
Looking at say, version information for the nsrd binary compared to the original 7.5.1 and the cumulative patch cluster, we get, for the original:
@(#) Release: 7.5.1.Build.269 @(#) Build date: Fri Mar 20 23:05:02 PDT 2009 @(#) Build info: DBG=0,OPT=-O2 -fno-strict-aliasing @(#) Product: NetWorker @(#) Build number: 269 @(#) Build arch.: linux86w
Then for the one installed this morning in the cumulative patch cluster:
@(#) Build date: Sat May 30 23:05:04 PDT 2009 @(#) Build info: DBG=0,OPT=-O2 -fno-strict-aliasing @(#) Product: NetWorker @(#) Release: 7.5.1.2 @(#) Build number: 323 @(#) Build arch.: linux86w
They are two very different – and very obviously different – builds. (So it’s not the case that I’ve say, been accidentally given the distributions as cumulative patch downloads.)
To me, sorry EMC, this is not good way of updating. Patches are either done as patches, in which case they’re issued by support and they’re standalone binaries/zips of binaries, or they’re done as new installs, in which case they are published and updated on PowerLink as well.
This pseudo, “six of one, half a dozen of another” is just going to all end in tears. For goodness sakes, if you go to the trouble of generating the patches as entirely new installs, do the following:
- Update PowerLink’s download section (currently showing “March 30”, not “May 30”).
- Notify users of the update.
Note – my complaint here is not that the patches have been issued as new releases of the software. My complaint is that it’s been done in such a way that it’s just going to create confusion by not making the new release readily available under PowerLink.