Re: letting scriptlets know they are in a rollback...

[James Olin Oden <joden malachi lee k12 nc us>]

On Mon, 2 Jun 2003, Jeff Johnson wrote:

> On Mon, Jun 02, 2003 at 11:03:35AM -0400, James Olin Oden wrote:
> > Hi All,
> > 
> > 
> > The rpm rollback on failure patch has been working like a charm for me,
> > except that I had one oversight (one that I know of).  The deal is
> > erase scriptlets need to know that they are in a rollback.  Previously,
> > the way I would handle this is in my upgrade and backout scripts that
> > called rpm, I would create a semaphore before a rollback occured that 
> > our scriptlets could check to see if they were indeed in a backout.  
> > This of course, assumed that rpm was called once to upgrade, and a second
> > time to rollback; my pass of course breaks that )-;.
> > 
> 
> Hmmm, I can't quite figger the context sufficiently to comment, *BUT* ...
> 
> > So what I want to know is how acceptable would a patch that creates an
> > environment variable if you are in a rollback transaction that the 
> > scriptlets could then check to see if they are in a rollback?  Or is there
> > a better way?
> 
> ... teaching scriptlets about state using the environment is paddling
> up the wrong stream. For starters, LSB is already mandating (but not
> specifying precisely, sigh) that scriptlets in LSB packages should not depend
> on their context, presumably so that the install-before-erase sequence of
> rpm can be unified with the erase-before-install dpkg paradigm.
> 
> Of course LSB (and dpkg) don't know diddly about --rollback <shrug>
>
There is the issue.  If you are going to do a rollback your scriplets do 
need to know if that is happening.  Now for RedHat packages, and other 
distribution packages, maybe not.  But for packages that are being used
to deliver administrative functionality (i.e. those editing config files,
adding users, ect) you really need that state information.  
 
> There are other reasons to avoid environment variables, so that the
> environment doesn't have to be bundled up and transported to execute
> a package script remotely. Yes, rpm currently (and traditionally)
> adds PATH and RPM_INSTALL_PREFIX* variables to the environment
> before executing scriptlets, but let's not go any farther down
> this pathway.
> 
> There are two approaches to the problem however, both are gonna need
> doing somewhen in rpm imho:
> 
> 	1) Expand scriptlet bodies, adding a self encapsulating
> 		export FOO="%{foo}"
> 	environment setup in the scriptlet preamble just like build scriptlets.
> 	This permits package scriptlets to be augmented on the install
> 	machine, also permits parameterization through string substitution.
> 
How difficult would this be?  Would you basically run rpmExpand on 
each line of the script (if I had my perl hat on, I would run it on the
whole file (-;)?  This would probably be safe, as macros that could have
been processed on the build machine were (right?).

> 	2) Extend the conventions for $3, $4, $5, etc to pass additional
> 	arguments. Redefining values for $1 and $2 is probably not possible
> 	at this point, but there's little reason (other than the difficulty
> 	of "standard"izing any change to rpm, sigh) why $3, $4, ... could
> 	not be used.
>
That sounds easiest, but long term is that what you want (i.e. have $3 be 
whether the transaction was a rollback transaction or not)?  I am 
obviously setting down the road to write another patch, but I want
to make sure that it fits in with your long term goals.

Thanks...james
> 73 de 
Jeff
> 
>