SD Custom Packaging, configure script SW_ env vars unexpectedly set

[Ralph Grothe]

Hi,

I currently try to swpackage a custom build of Perl 5.10.0.
Having written the PSF this all works smoothly,
except that some of the exported SW_* variables that the man pages of swpackage, swconfig etc. state expand other than anticipated.

In the product context of the PSF I tagged my control file like this:

# grep control_file perl-5.10.0-hppa-11.11.psf
control_file /usr/local/perl/perl-5.10.0-hppa-11.11.ctl=configure
control_file /usr/local/perl/perl-5.10.0-hppa-11.11.ctl=unconfigure


After having installed my depot I could verify that for both tags control scripts for {,un}configure scripts indeed got installed by swinstall.

# ll /var/adm/sw/products/Perl510/pfiles/*configure
-r-xr--r-- 1 root sys 1114 Aug 21 13:33 /var/adm/sw/products/Perl510/pfiles/configure
-r-xr--r-- 1 root sys 929 Aug 21 11:36 /var/adm/sw/products/Perl510/pfiles/unconfigure



Please note, both scripts were exactly identical after swinstall (what I intended).
The difference in size is merely owed to my modifying of configure afterwards to rerun it via "swconfig -x reconfigure=true" without having to repeatedly swinstall the whole chunk over and over.

To only have to supply one script for all filesets and script execution stages like preinstall, postinstall, configure, verify etc.
in it I refer to the exported vars SW_CONTROL_TAG and SW_SOFTWARE_SPEC like so
e.g.

fileset=${SW_SOFTWARE_SPEC%%,*}

because this should work if SW_SOFTWARE_SPEC during script execution had the same value that swlist pretends for my filesets.

# swlist -l fileset -x one_liner="tag state software_spec" Perl510|grep ^[^#]
Perl510.PERL-LIB PERL-LIB Perl510.PERL-LIB,l=/,r=5.10.0.A,v=ITDZ configured
Perl510.PERL-MAN PERL-MAN Perl510.PERL-MAN,l=/,r=5.10.0.A,v=ITDZ configured
Perl510.PERL-RUN PERL-RUN Perl510.PERL-RUN,l=/,r=5.10.0.A,v=ITDZ configured

or parsed

# spec=$(swlist -l fileset -x one_liner="tag state software_spec" Perl510|awk '$1~/RUN/{print$1}')

# echo ${spec%%,*}
Perl510.PERL-RUN

Because in my control script I match for the "RUN" part in a case block, I at least need this sub string to identify which control stage (viz. configure, unconfigure etc.) I am in.

So I inserted these lines in the script to check what got printed in the swjob listing.

printf "SW_SOFTWARE_SPEC is: ";printenv SW_SOFTWARE_SPEC
printf "SW_CONTROL_TAG is: ";printenv SW_CONTROL_TAG
echo "Fileset is $fileset"

but this is what the vars' values look like:
(where has the "RUN" part gone?)

SW_SOFTWARE_SPEC is: Perl510,l=/,r=5.10.0.A,a=,v=ITDZ
SW_CONTROL_TAG is: configure
Fileset is Perl510


So is there a better way to distinguish in the control script which of the various install/uninstall stages currently gets executed?

Rgds
Ralph

[Ralph Grothe]

I additionally added an env statement in the control script.
So this is what the contents of the SW_* related env vars, as set when running swconfig, look like:

SW_ADMIN_DIRECTORY=/var/adm/sw
SW_CATALOG=/var/adm/sw/products
SW_CMD_NAME=swconfig
SW_COMPATIBLE=
SW_CONTROL_DIRECTORY=/var/adm/sw/products/Perl510/pfiles/
SW_CONTROL_TAG=configure
SW_DEFERRED_KERNBLD=
SW_DLKM_REPLACEMENT=
SW_HW_SUPP_BITS=64
SW_KERNEL_PATH=/stand/vmunix
SW_KERN_BIT_MODE=64
SW_LOCATION=/
SW_MODIFY_TMPDIR=/var/adm/sw/swmodify_itmp/
SW_PATCH512B=1
SW_PATH=/usr/lbin/sw/bin:/var/adm/sw/sbin:/sbin:/usr/bin:/usr/ccs/bin
SW_POSTDSA_TEMPFILE=
SW_ROOT_DIRECTORY=/
SW_SESSION_IS_KERNEL=
SW_SESSION_IS_REBOOT=
SW_SESSION_OPTIONS=/var/tmp/CAAa29436
SW_SOFTWARE_SPEC=Perl510,l=/,r=5.10.0.A,a=,v=ITDZ
SW_SOURCE_DIR=
SW_SOURCE_HOST=
SW_SYSTEM_FILE_PATH=/stand/system
SW_VERBOSE=0

[Ralph Grothe]

Could it be that SW_SOFTWARE_SPEC doesn't contain the fileset part
because I haven't put separate control_file statements in the various fileset sections in my spec file?
As I understood from what I read in (or maybe gathered from) the manpages, control_file statements in the product section should suffice since they would automatically apply to each fileset of the product as well.
Maybe this is my wrong assumption?
I will try...

[Ralph Grothe]

Found the answer by trial and error.
See this thread
http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1261513

[James R. Ferguson]

Hi Ralph:

It's too bad that you can't give yourself points :-)

You invariably do a great job of answering most of your own questions as you post.

Thanks for sharing.

Warmest regards!

...JRF...

[Ralph Grothe]

While sifting through SD related stuff
I came across this neat func lib for swpackaging that HP already have provided for us:
/usr/lbin/sw/control_utils

Sourcing these funcs in your control files doesn't only relieve one from reinventing things,
but has the added benefit that your scripts are less likely to break when HP change filesystem locations, environment etc. of SD tools.

[Dennis Handly]

>Could it be that SW_SOFTWARE_SPEC doesn't contain the fileset part because I haven't put separate control_file statements in the various fileset sections in my spec file?

We have our control scripts under each fileset.
Also, we have separate control scripts so looking at SW_CONTROL_TAG isn't that helpful.

>control_file statements in the product section should suffice since they would automatically apply to each fileset of the product as well.

I don't think so, they would only apply at the product level.

[Ralph Grothe]

Hi Dennis,

now I think to have sorted out what parts of control files in which sections of the PSF are required.
Though my approach at first made it a bit more error prone I could stick to one control file for all stages of pre/postinstall, un/configure request, postremove etc.
This now works fully to my expectations.
Meanwhile I also found out how to fetch the SD jobid (and all the other parameters).
SD sets the env var SW_SESSION_OPTIONS which points to a temporary file created for the current stage which has param/value pairs.
So in my script I can simply do something like

jobid=$(grep jobid=$NODE $SW_SESSION_OPTIONS|cut -d= -f2 | tr -d \\040)

Though this (especially the tr) may look pretty odd, it took me a while until I relized that the values were stored with trailing whitespace. In Perl one would have simply chomped.

[Dennis Handly]

>cut -d= -f2 | tr -d \\040)
>Though this may look pretty odd, it took me a while until I realized that the values were stored with trailing whitespace.

That's why you don't use cut(1). Use awk instead. Probably:
awk -F"[= ]" '{print $2}'

Hmm, that's probably not much better if you have spaces before the "=".

[Ralph Grothe]

I know, I usually also use awk for that.
And I could well use -F= as field separator in awk's invocation because there is no whitespace around the equals sign.
Still, all the dumped SD attributes from $SW_SESSION_OPTIONS exhibit one trailing whitespace.
You can easily check for yourself if you choose to modify for instance a configure script of one already installed (uncritical) package of yours under /var/adm/sw/product/SomeProduct/SomeFileset/configure
and squeeze in a statement like

cat $SW_SESSION_OPTIONS > /tmp/sw_sesopts.dump

which you can inspect after you have executed

# swconfig -v -x reconfigure=true SomeProduct.SomeFileset

Note, that the configure script in your $SW_CONTROL_DIRECTORY will be read-only
and that after you have modified the configure script any swverify afterwards will complain because of wrong file size/checksum.
But if you chose an uncritical product these changes are quite harmless I would think and easy reversible.

[Ralph Grothe]

Oops, sorry.
You were of course absolutely right.
I overlooked that you gave awk's -F switch a character class of equals sign *and* whitespace.
So yes, your solution is much better than my pipe clutter.

# awk -F'[= ]' '$1=="jobid"{print$2}' /tmp/Perl510.PERL-RUN.configure.gomera-0293\ |cat -e
gomera-0293$

[Dennis Handly]

>gave awk's -F switch a character class of equals sign *and* whitespace.

Actually it's just a regular expression.
A character class would be: [:alpha:]

[Ralph Grothe]

Ok, not going to split hairs.
Btw, is this an understandable idiom in English
(in German we say, Haarspalterei; i.e. pettifogging)