Can one run swremove inside a swinstall session?

[Jeff Schussele]

All,

I'm repackaging gzip 1.3.3 & during it's install I wish to remove the standard HP gzip 1.2.4 that's in the SW-DIST.GZIP fileset. My package will install 1.3.3 into /usr/local/bin & I want to remove the standard gzip from /usr/contrib/bin & then link 1.3.3 to /usr/contrib/bin. I'm trying to avoid having to swremove it manually prior to the 1.3.3 install.

The question I have is can I run swremove in the configure script run by swinstall? Is this possible or even allowed?

TIA,
Jeff

[Sridhar Bhaskarla · Accepted solution]

Jeff,

It is not possible to do it as the target (/) would be locked by your swinstall session.

Try to doing swinstall. While it is running, then execute swremove to remove a dummy depot. It should give out error.

-Sri

[Helen French]

It is not possible to do that. You will get an error message like this "The target or source is already in use either within this same session or by another sesion. A read or write lock was denied."

[Patrick Wallek]

Hey Jeff,

Hmm..... Interesting question.

I just tried an experiment. It's not exactly what you're asking, but it may help you.

I invoked a swinstall session (GUI) and then while that was running invoked a swremove (GUI) session. The swremove did not behave correctly. When swremove was invoked it came up and asked me to "select the target path". If I just click on OK to accept the '/' path then it comes up with a message that basically the target / source is already in use and a read or write lock was denied.

So I think the answer to your question is probably no, it won't work.

Are you going to automate this install? If so, how about just throwing together a little shell script that will do your swremove, make sure it completed successfully and then invoke your swinstall to install the new gzip stuff?

I think that'd be easier.

Good luck.

[S.K. Chan]

As others have put it, you just can't. You may get away by removing the swlock file (the first time because subsequent session will recreate swlock)in /var/adm/sw/products but that would compromise the integrity of SD.
my $0.02

[Jeff Schussele]

Ok, was afraid of that.
That's why I asked before I expended the effort.
Oh well....on to Plan B.

Thanks guys.

Patrick - good idea, but this has to be a standard pkg that's depoted and even Jr. SAs can run. Would possibly end up on hundreds of systems.

*****HP IF YOU'RE LISTENING*****

We NEED a gzip that can handle +2Gb files RELIABLY.
PLEASE give us a patch to supersede SW-DIST.GZIP with the 1.3.3 version. Ignite frequently gives up the ghost when it hits +2Gb files. PLUS our DBAs are always complaining about the std gzip not handling these filesizes.

Rgds,
Jeff

[Patrick Wallek]

Hmmm....OK, how about a bit of a different approach then. Do you have a server that can act as a depot server?

Create your depot, register it on your depot server. Then just write your little script that'll do the swremove, swinstall, etc. and have your JR. SA's run that. You would have some network traffic as it pulled the new gzip down from the depot server, but I don't think that would be much.

If you Jr. SA's can't run a script, well........

[Jeff Schussele]

I hear you Patrick.
It's a matter of scale.
You'd have to distribute the script to the servers & then they'd have to remember to run the script instead of just swinstalling the pkg.....
I'm just attempting to keep it as absolutely simple as possible.

Of course, the simplest thing would be IF HP would ship a current gzip with SD or at least give us a superseding patch.

Thx,
Jeff

[Bob_Vance]

My $.02 :

You might want to think twice about this, anyway, for a couple of reasons.

The GZIP is a fileset of SW-DIST for a reason.

The /usr/contrib/bin/gzip is used internally by a couple of commands, by default. If you change the version of gzip, there could, theoretically, be an issue of support from HP.

Further, you could create a problem for future patches or upgrades to SW-DIST.

Also, /usr/contrib/bin has a somewhat special status with make_tape_recovery -- messing with it, specifically symbolic links, might cause problems. (E.g., I used to make it a symbolic link, but the restore didn't like that, because it had already created the directory. Of course, I could manually recover from the situation, but it just wasn't "clean").

Anyway, I hesitate to mess with the standard HP stuff.

Why not just have the newer package, *in addition* to SW-DIST.GZIP, and just be sure that, when you *know* you need it, either call it absolutely or have local/bin before contrib/bin in PATH.

OTOH, if you're not worried about HP support issues, your new package could simply replace the files in contrib/bin, perhaps after saving the old versions of the relevant files (e.g., gzip --> gzip.1.2.4). I don't think that the disappearance of SW-DIST.GZIP from a system particularly gains you anything. If you're worried about seeing what's on the system, the mere appearance of your new GZIP.1.3.3 package is just as good an indicator as the absence of SW-DIST.GZIP.

But, here, you still have an issue that future patches or upgrades to SW-DIST could replace your new executables.

Just some food for thought.


bv