This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.
>>>>>
>>>>> 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.

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.

Max.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]