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 <http://cygwin.com/ml/cygwin-apps/2006-03/msg00060.html>? > >>>>> 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"? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] | [EMAIL PROTECTED] 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"
