list of all superseded HP-UX patches

[Darren R. Lauser]

Hello,

Is there somewhere from whence I can download a list of all superseded HP-UX patches? Thanks. Not the patches themselves, just a list of the patch names.

My purpose is to go one step further than the cleanup command. It can commit patches when it sees that a newer patch is already installed. I would like to commit any patch that has been superseded, even if the newer patch has not been installed.

It would be even better if the list provided the highest rating (number of stars) for any patches that have superseded it.

Regards,
Darren

[James R. Ferguson]

Hi Darren:

I don't necessarily know how you might download a list of all superseded patches. In fact, there will be patches that you don't have installed at any level because they simply don't apply to your environment or installed products.

This said, you can "go-further" than 'cleanup' allows and commit all patches with:

# swmodify -x patch_commit=true \*

A convienent way to see your active and/or superceded patches is to run:

# show_patches -a -s

Regards!

...JRF...

[Darren R. Lauser]

Hi James,

Thanks for the note. I have done that occasionally, when I remember, before I apply a tested patch bundle. But, I cringe as I do, since I could potentially be committing a bad patch. If I knew that there was a superseding patch in existence for each patch that I was commiting, then it would be far less risky.

Regards,
Darren

[OldSchool]

"was a superseding patch in existence for each patch that I was commiting"

that, to me, is falacious logic. IF the patch has been superceded, that would indicate that the existing/installed patch is not sufficient...

[James R. Ferguson · Accepted solution]

Hi (again) Darren:

> I have done that occasionally, when I remember, before I apply a tested patch bundle. But, I cringe as I do, since I could potentially be committing a bad patch. If I knew that there was a superseding patch in existence for each patch that I was commiting, then it would be far less risky.

Yes, the suggestion was made with the assumption that one does it only when one is sure that things have been running for months without incident. The idea is indeed to have a new stable baseline from which a new patch cycle can begin.

I would suggest using SWA (the Software Assistant Tool) to query the ITRC patch dataebase to see what applies to your server.

Regards!

...JRF...

[Darren R. Lauser]

Hi Oldschool,

Thanks for your note.

> IF the patch has been superceded, that would indicate that the existing/installed patch is not sufficient...

We can disagree about that. A superseded patch is not necessarily bad. Quite often it is just a corner case tweak.

Here is my logic; IF the patch has been superceded, THEN I will never need to remove it.

The only risk to commiting a patch is that you can no longer remove it without restoring the saved "rollback" files in /var/adm/sw/save. If there is a newer patch, then I would apply that, if needed, rather than removing the existing patch.

Regards,
Darren

[Bob E Campbell]

The full set of patches is (with gothchas) available in a couple of forms at the moment, but none of them are currently supported APIs (we reserve the right to change them at any time).

Most of the things I am thinking about are found under ftp://ftp.itrc.hp.com/export. If you really wanted a supported method the patch information is also extractable from the patch text files.

I do not really recommend that process, as the fact that a new patch exists should not imply that it is recommended. The superseding patch might have a critical warning against it.

You could use the list of installed patches together with SWA to determine those that have a recommendable successor using the CHAIN analyzer.

[Darren R. Lauser]

I haven't yet tried SWA, so that is probably what I am really wanting. The ftp site looks promising, if SWA doesn't fit the need.

Thanks.