This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH] setup: fix abnormal exit test for postinstall scripts
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.
>>>>> Perhaps renaming to ".failed" would be better that not renaming.
>>>> 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.
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.