10-06-2013 01:39 AM
Hi. I am coming from Linux/Solaris background, so - I have no much experience with HP administration.
WE are preparing procedure for installing ORACLE and Postures DB systems in our environments. On Solaris and Linux ORACLE (and PG) requirements generally include lists of packages to be installed info their minimal versions(for example - libstdc++-3.4.5-2).
Why in case of HP - requirements are formulated in terms of patches and patch bundles? Does it means that HP have no mechanism of updating one specific package to some specific version?
One - I am just curious...
Second - it causes us to write separate logic for SOlaris/Linux and for HP. (Checking specific patches and and their supersedes instead of versions of specific packages..).
Another question is - what if let us say PHKL_35900 or some its supersede will be installed not as separate patch, but as part of some patch bundle... Will standard "swlist" command show me that it is installed? If my patch (that means - patch that I have to check) is "buried" in some patch bundle installed on system - how can I figure out - that it is present in system?
Solved! Go to Solution.
10-06-2013 06:12 AM
In Linux and Solaris, one package file = one unit of software that is either installed or not.
In HP-UX, the principles of software packaging system are different: a single depot file can contain multiple filesets that can be independently installed. Those filesets can be grouped as subproducts, products, and/or bundles. As another distinction, each fileset can be either a "base" fileset (containing a complete set of installable files) or a "patch" fileset (replacing one or more files of an already-installed base fileset).
Because of this hierarchical layout, running "swlist" without any options is not so useful when you're checking for software installation requirements: it only gives you a top-level overview, not the whole story.
You'll need to drill down a bit deeper in the SD-UX (= HP-UX Software Distributor, the formal name of the HP-UX software packaging system) hierarchy:
swlist -l fileset -a supersedes
This will list all filesets, so all the installed patches will appear, even if they are part of a patch bundle. The "supersedes" attribute of each fileset will also be displayed, which should allow you to recognize that a newer patch fileset has superseded the patch you're looking for.
10-06-2013 05:57 PM - edited 10-06-2013 06:01 PM
>Does it means that HP-UX have no mechanism of updating one specific package to some specific version?
It depends on whether you are going to a newer patch (kernel or runtime) or for separate software product.
The former contains a delta of the files needed. The latter contains the whole thing.
>If my patch is "buried" in some patch bundle installed on system - how can I figure it is present in system?
You can also use:
swlist -l patch PHxx_##### ...
Where you list each specific patch you want to check.
10-07-2013 01:13 AM
Hi Guys. First - thanks for responses. It was of great help.
What I really do not understand here is follows:
Let us say - I have patch PHxx_AAAA - that patch libstc++ to version A and and glibc to version B.
Now - let us say I have PHyy_#### that update 7 packages and among them libstdc to Version A1 - higher then A, and patch PHzz_#### that update another 11 packages and among them glibc to version B1 - higher then B.
No one of those patches is supersede of PHxx_AAAA. But packages that we (or ORACLE) need - are patched to level that is required... Can such situation occur practically? Have I some way to discover it?
10-07-2013 01:52 AM
>I have patch PHxx_AAAA - that patch libstc++ to version A and and glibc to version B.
That's not going to happen for many reasons.
1) Opensource doesn't provide patches, only complete depots. You need to talk about HP-UX products/patches.
2) Patches aren't likely to update different products.
>I have PHyy_#### that update 7 packages and among them libstdc to Version A1 - higher then A, and patch PHzz_#### that update another 11 packages and among them glibc to version B1 - higher then B.
Again that's not going to happen. Patches aren't going to update different things, only one product/package. They need to be cumulative.
>No one of those patches is supersede of PHxx_AAAA.
That's right. They MUST be able to supersede previous patches but with your above scheme, they can't.
It might help if you ask questions about a real example.
10-07-2013 02:45 AM
>Again that's not going to happen. Patches aren't going to update different things, only one product/package. They need to be cumulative.
Ok - I think this is a key sentence... If HP patches are always built those way, situation , that I described - can not ocur in practice...
Thanks a lot...