[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Tue, 3 Jun 2003, Jeff Johnson wrote:

> On Mon, Jun 02, 2003 at 06:54:30PM -0400, James Olin Oden wrote:
> > > 
> > > 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.  
> >  
> Can you provide an example package (in bugzilla, lest we be boring ;-)
> that needs to "know" the difference between erase and rollback?
Yes I will look into doing this.  I have plenty, thus just may need 
sanitizing, so If I could distill it down to a very simple case then
that would be best.
> Certainly, scriptlets need to distinguish erase-during-upgrade from
> pure-erase, but I'm having trouble seeing the need for detecting rollback.
> Ah yes, rollback is an erase-before-install-before-erase, so, if you
> are executing scriptlets during the rollback pass, you will need
> some way to condition the logic.
> But that presents the slightly different question:
> 	Why are you (or rpm ;-) running scriptlets during the
> 	repackage pass?
> Whack in the --noscripts --notriggers bits to disable scriptlet execution
> during repackaging is the better fix.
> Or am I missing something?
You are I think, but I am afraid everytime I look at the rpm code and 
think I understand some portion, inevitably I am missing something (-;

Take this scenario.  You have a pakcage that turns on various services
at install time, and on an upgrade it may need to turn on only a portion 
of these as some may already be on.  In an erase it needs to turn off all
the services it could have turned on, but in a rollback it only needs
to turn off the services that were turned on since the last upgrade. 
Now keeping information about what services were turned on last is
not germaine to rpm (not yet (-;).  But, certainly, and this is 
especially true with an atomic rollback of a failed transaction, the rpm
that is clearly being used to perform administrative task (and yes I 
suppose its being used for file management) needs to know when its 
erase scriptlets are being ran in an rollback.  

> Pretty trivial. At the appropriate place in runScript(), add
> 	script = rpmExpand(script, NULL);
> Since rpm is about to exec, there's no need to free.
I think then I will take that approach.  
> A more general framework for adding glop before and after specifically named
> scriptlet bodies, like the build scriptlet framework, is needed, easy but
> tedious.
Could you explain this more, because I might be able to do some of that in 
such a patch (no promises, but certainly I can try).
> > 
> Easier than the 1 line above? Truly, changing the number of args passed to
> scriptlets is harder, gonna need a tracking dependency to attempt to
> associate a package with needed functionality, which slows the deployment
> down by 6-12 months.
I stand corrected.  I have been glancing it the psm a bit more and I can 
see what you mean.

Thanks Jeff...james 
> 73 de Jeff

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []