Identifying software dependencies before removal

[Ralph Grothe]

Hello,

I wonder whether the HP SD has a feature similar to Linux RPM's "rpm -qf /some/weird/file",
to identify what software depot smuggled in certain files.

Because of disk space waste I want to get rid of one of my three (sic!) Java runtimes.
I asked the application folks what Java version their apps did rely on.
The Java 1.2 fossil was obviously not needed,
whose removal would free up nearly 70 MB.

# du -skx /opt/java1.?
69992 /opt/java1.2
77728 /opt/java1.3
173360 /opt/java1.4

As designated Java depots I however can only identify the latter two

# swlist|grep -i java
B9788AA 1.3.1.02.01 Java 2 SDK 1.3 for HP-UX (700/800), PA1.1
+ PA2.0 Add On
B9789AA 1.3.1.02.01 Java 2 RTE 1.3 for HP-UX (700/800), PA1.1
+ PA2.0 Add On
T1456AA 1.4.2.10.00 Java2 1.4 SDK for HP-UX
T1456AAaddon 1.4.2.10.00 Java2 1.4 SDK -AA addon for HP-UX

But none of these depots has files beneath /opt/java1.2

# swlist -l file B9788AA B9789AA T1456AA T1456AAaddon|grep -c /opt/java1\.2
0


Looks to me as if the Java 1.2 stuff was part of the base OE.

Hm, but I seem to have several references in various INDEX files

# find /var/adm/sw/products -type f|xargs grep -l java1\.2
/var/adm/sw/products/INDEX
/var/adm/sw/products/Java-PlugIn1-2/pfiles/INDEX
/var/adm/sw/products/Java-PlugIn1-2/JAVA2-PLUGIN/INFO
/var/adm/sw/products/Java2RTE_base/pfiles/INDEX
/var/adm/sw/products/Java2RTE_base/JAVA2-JRE-BASE/INFO
/var/adm/sw/products/Java2RTE_doc/pfiles/INDEX
/var/adm/sw/products/Java2RTE_doc/JAVA2-JRE-DOC/INFO
/var/adm/sw/products/Java2RTE_perf/pfiles/INDEX
/var/adm/sw/products/Java2RTE_perf/JAVA2-JRE/INFO

This is a bit of a catch because before I can swlist check for prerequisite tags I need to know the name of the depot to whom /opt/java1.2 belongs.

I would rather like to swremove than simply "rm -rf /opt/java1.2".
There may be some critical app that depends on exactly this version of Java that we don't know about.

Btw, the Linux RPM has a --provides switch which is better than checking all packages if they require a certain package.
Is that inverse logic also available with SD?

Regards
Ralph

[Steven E. Protter · Accepted solution]

Shalom,

Try swremove -p

That will let you know what SD/UX components are using the depot.

The problem here is that Oracle is generally not installed via depot files (Though I know how I'd do it). You can still break things even if SD/UX says its okay.

SEP

[Ralph Grothe]

Hello SEP,

thanks for the reminder of the -p switch.
I think to have identified the filesets to which the /opt/java1.2 belongs.
When I run swremove of them with the -p switch there seem to be no complaints of hindering dependencies.
Of course, you can't have a 100% safety guarantee in a free world, can you?

# swlist -l fileset|awk '$1~/^Java2RTE/{print$1}'|xargs swremove -pv

======= 08/23/06 11:17:40 METDST BEGIN swremove SESSION
(non-interactive) (jobid=somehost-0081)

* Session started for user "root@somehost".

* Beginning Selection
* Target connection succeeded for "somehost:/".
* Software selections:
Java2RTE_base.JAVA2-JRE-BASE,l=/opt/java1.2,r=1.2.2.11.01,a=HP-UX_B.11.00_32/64,v=H
P,fr=1.2.2.11.01,fa=HP-UX_B.11.00_32/64
Java2RTE_doc.JAVA2-JRE-DOC,l=/opt/java1.2,r=1.2.2.11.01,a=HP-UX_B.11.00_32/64,v=HP,
fr=1.2.2.11.01,fa=HP-UX_B.11.00_32/64
Java2RTE_perf.JAVA2-JRE,l=/opt/java1.2,r=1.2.2.11.01,a=HP-UX_B.11.00_32/64,v=HP,fr=
1.2.2.11.01,fa=HP-UX_B.11.00_32/64
* Selection succeeded.


* Beginning Analysis
* Session selections have been saved in the file
"/root/.sw/sessions/swremove.last".
* The analysis phase succeeded for "somehost:/".
* Analysis succeeded.


NOTE: More information may be found in the agent logfile using the
command "swjob -a log somehost-0081 @ somehost:/".

======= 08/23/06 11:17:46 METDST END swremove SESSION
(non-interactive) (jobid=somehost-0081)

[Steven E. Protter]

One can never be sure.

I'd scan configuration files with a grep command for JAVA and JAVA_PATH and JAVA_HOME variables pointing to the old JAVA, if you know there is significant software that depends on java but does not get installed by SD/UX.

The reason management should pay for test boxes is so we can safely test this stuff.

SEP

[Ralph Grothe]

Good hint,
I ran a quick find for local dot files,
and luckily none of those seems to reference the old Java version as part of a path.

# find / -local -type f -name .\*|xargs file|awk -F: '/text/{print$1}'|xargs grep -l java1\.2