This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH] setup: fix abnormal exit test for postinstall scripts
On Thu, 16 Mar 2006, Max Bowsher wrote:
> Igor Peshansky wrote:
> > On Tue, 14 Mar 2006, Max Bowsher wrote:
> >> Igor Peshansky wrote:
> >>> On Thu, 9 Mar 2006, Dave Korn wrote:
> >>>> On 09 March 2006 23:14, Max Bowsher wrote:
> >>>>>>> * script.cc (Script::run): Fix inverted test for abnormal exit.
> >>>>>>> Do not rename to ".done" unless completed successfully.
> >>>>>> And ping (attached as "setup-script-exit-code-fix.patch").
> >>>>> Do we necessarily want to try to re-run failed scripts the next
> >>>>> time setup installs some packages?
> >>> Why not? It would make recovery from a hosed install because of
> >>> in-use DLLs easy enough -- just re-run setup and select "Keep",
> >>> which will only rerun the postinstall scripts.
Speaking of in-use DLLs, did you have a chance to look at
> >>>>> Perhaps renaming to ".failed" would be better that not renaming.
> >>>>> Max.
> >>>> Perhaps setup should check when you first start it up whether
> >>>> there are any postinstall scripts left lying around from last time
> >>>> and offer to run them for you then and there? Failed postinstalls
> >>>> should be run to completion *before* next updating the package!
> >>> Why? I'm not so certain. So your preremove will fail -- who cares,
> >>> it would also fail if "cygwin" is upgraded and is uninstalled before
> >>> the preremove script is run. Next time you upgrade, it'll be like
> >>> the initial install all over again, and the *new* postinstall will
> >>> run. If you didn't touch the package, however, the postinstall that
> >>> failed before will be re-run. If it failed because of something in
> >>> the environment when setup was run (e.g., a stale DLL in memory), it
> >>> will now succeed and will be renamed to .done. If it fails again,
> >>> we'll know something was wrong, and will recommend looking at the
> >>> output in setup.log.full.
> >> I'm concerned about introducing weird subtle edge cases. For example:
> >> Upgrade package in which old version has preremove, new version does
> >> not. preremove fails. Next time setup runs, stale preremove zaps parts
> >> of the upgraded package.
> >> Granted, it's a fairly tenuous situation, but at least the current
> >> behaviour is very predictable: scripts are only re-run manually.
> > Umm, we can never have stale postinstalls and preremoves, since those
> > are part of the manifest (pkg.lst) and will be removed by the
> > "uninstall" part of the upgrade. The only way we can have a stale
> > postinstall is if it no longer has the name in the manifest (i.e., is
> > renamed to ".done"). Am I missing something?
> Ah, I hadn't thought of that.
> So, I think we should always rename preremove scripts, because we
> certainly don't want a failed preremove script to be removed by the
> later file-removal phase - it might be wanted for debugging.
I would even go one step further, and cancel the uninstall of the current
package and all packages it depends on if the preremove failed. But
that should be a separate patch.
> As for postinstall scripts ... I think ideally it would be a separate
> operation (c.f. 'dpkg --configure --pending'), but I guess we can go
> with the simple solution for now, and defer a more complex solution
> until someone has the inclination.
So, does this mean "please check in"?
|\ _,,,---,,_ firstname.lastname@example.org | email@example.com
ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"