Does swinstall honour external influence by e.g. extra args or env?

[Ralph Grothe]

Hi,

I still elaborate on my swpackage control files.
I would like to offer the person installing my depot some more influence on how the package be installed, somethings one would normally in publicly distributed depots not allow.
I thought of some extra options or environment settings that would coerce the swinstall into some kind of ruder, more intrusive behaviour.
For instance, as this is a Perl depot, I would like swinstall to rename the perl binary in /usr/bin and instead put the depot's one in place or link to it symbolically, but only when explicitly asked for this.
Obviously you wouldn't want your production box to suddenly fail executing the mundane Perlage because the new @INC lacks that very module the packager forgot to supply.
The user installing the depot shouldn't be bothered any further with SD intricacies other than the most basic swinstall command, plus maybe that little extra flag if swinstall allows for this.

Ralph

[James R. Ferguson]

Hi Ralph:

You might be able to leverage 'SW_LOCATION' which tells scripts where the product files are located.

http://docs.hp.com/en/B3921-60631/swinstall.1M.html

Regards!

...JRF...

[James R. Ferguson · Accepted solution]

Hi (again):

Another possiblity is to use '-x ask-true' in the 'swinstall'. See the aforementioned manpages for 'swinstall' at the link I posted.

Regards!

...JRF...

[Ralph Grothe]

Hi James,

sorry for my delayed response.
Yesterday, before your great hint arrived I was already off the office.

Fantastic, SD even has an swask command,
that up until now I haven't known it even existed.
In the manpage of swpackage there correspondingly appears a control file called "request" in the relevant section that somehow has completely escaped my notice.
I should more carefully read the manpages next time. It's all there.
Thanks a lot for pointing my nose in the right direction!

Cheers
Ralph

[Dennis Handly]

>swinstall honour external influence by e.g. extra args or env?

No. Any variables you may set aren't passed to the swagentd, which was started N days ago. :-)

[Ralph Grothe]

Hi Dennis,

sorry, to object.
But it does really work if you provide a cotrol_file either named or tagged "request".
In the control_file you just have to provide a block which gets executed for §SW_CONTROL_TAG == request.
Here you can echo screens to stdout of the person installing and read input from his stdin,
provided he has started the swinstall with the flag -x ask=yes or -x ask=as_needed.
In this block you would then redirect any output, that your configure block will later base its logic on, to a file called ${SW_CONTROL_DIRECTORY}response.
In the configure phase, which is always executed after the require stage, you parse this file and derive the further configuration path from this input.
This way I could implement the more ugly things like replacing the current system's perl binary in /usr/bin, which I would only like to do if explicitly asked for.
It really works nicely.
I still try to gather other bits of information.
For instance I haven't yet found out,
how to retrieve the current jobid of the swinstall process.
Should anyone be interested I could post snippets of my PSF and control_file.

[Dennis Handly]

>But it does really work if you provide a control_file either named or tagged "request".

I was pointing out why env vars wouldn't work, not swask or request scripts.

[Ralph Grothe]

Yes of course, as far as env vars are concerned you're right.
But as the swask stuff works for me I don't need to reflect on the environment anymore.