Re: Fix setup bug handling missing dependencies in unattended modes

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Fri, Dec 10, 2010 at 06:36:01PM +0000, Jon TURNEY wrote:
>
>Here's a patch to fix a rather obscure setup bug, which I believe is probably
>behind the bug report [1]
>
>Test case:
>1/ Run setup -M
>2/ In the package chooser, uninstall a package which is a dependency of an
>installed package
>3/ Click next
>
>[1] http://cygwin.com/ml/cygwin/2010-12/msg00178.html

>From 6d08fc3ff64b841b468d77755cae8d10fef242b4 Mon Sep 17 00:00:00 2001
>From: Jon TURNEY
>Date: Fri, 10 Dec 2010 18:20:45 +0000
>Subject: [PATCH] Fix bug with prereq warning page in unattended modes

Huh?

>If you run setup -M and remove a package which is a dependency of another
>installed package, setup fails to advance, and gets stuck in the dependency
>checking progress page.
>
>Returning 0 to OnUnattended() seems inadvisable.  This makes PSN_SETACTIVE
>get a return value of -1, which, according to the documentation, "activate[s]
>the next or the previous page (depending on whether the user clicked the Next
>or Back button)."  If no button has actually been clicked (which will usually
>be the case in unattended mode), it seems to select the next page in the
>order defined by the propsheet.
>
>Normally, this is fine.  But the next page in this sequence after IDD_PREREQ
>is IDD_INSTATUS, which appears several times in the actual sequence to report
>the status of different tasks, and the work it does is controlled by
>ThreeBarProgressPage::SetActivateTask().  If we advanced to IDD_INSTATUS without
>changing the task, it will repeat the previous one.
>
>In chooser-only mode, allow activation of the dependency warning page to succeed.
>In unattended mode, advance to install or download task as appropriate.
>
>(Also, update comment to clarify meaning of OnUnattended() returning 0)
>
>(Other users of a return value of 0 in OnUnattended() are SplashPage (which is
>the first page), and PostInstallResultsPage, both of which are fine as the
>next page in the propsheet sequence is the correct one, although an explicit
>use of OnNext() would be clearer)

Patch looks ok.  Please check in (with a ChangeLog of course).

Thanks.

cgf