From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97803 invoked by alias); 9 Nov 2017 16:42:41 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 97724 invoked by uid 89); 9 Nov 2017 16:42:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2059, H*r:ip*192.168.0.15, convinced, no X-HELO: limerock03.mail.cornell.edu Received: from limerock03.mail.cornell.edu (HELO limerock03.mail.cornell.edu) (128.84.13.243) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 09 Nov 2017 16:42:38 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock03.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id vA9GgZDs031886 for ; Thu, 9 Nov 2017 11:42:36 -0500 Received: from [192.168.0.15] (mta-68-175-129-7.twcny.rr.com [68.175.129.7] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id vA9GgYs6022471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 9 Nov 2017 11:42:35 -0500 Subject: Re: [PATCH setup 0/2] Improve behavior after download error To: cygwin-apps@cygwin.com References: <20171106214907.7120-1-kbrown@cornell.edu> <22b83ed0-2778-92d3-59db-82c0bf74b4cd@SystematicSw.ab.ca> <68e45b08-4d85-18dc-4fd2-fd3f72296880@dronecode.org.uk> From: Ken Brown Message-ID: <8806d1c4-1b07-a279-582d-285249af98c6@cornell.edu> Date: Thu, 09 Nov 2017 16:42:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <68e45b08-4d85-18dc-4fd2-fd3f72296880@dronecode.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00034.txt.bz2 On 11/9/2017 8:21 AM, Jon Turney wrote: > On 08/11/2017 18:52, Brian Inglis wrote: >> On 2017-11-08 07:35, Ken Brown wrote: >>> On 11/7/2017 1:56 PM, Jon Turney wrote: >>>> On 07/11/2017 04:28, Brian Inglis wrote: >>>>> On 2017-11-06 14:49, Ken Brown wrote: >>>>>> This is a followup to >>>>>> https://sourceware.org/ml/cygwin-apps/2017-11/msg00003.html.  The >>>>>> focus of that thread was a crash that occurs on the topic/libsolv >>>>>> branch.  Here I'm more interested in a UI issue.  Namely, I don't >>>>>> think it's reasonable that setup goes back to the site page if the >>>>>> user clicks Yes in response to "Download Incomplete. Try again?". >>>>>> This is not what the message says will happen, and I'm not convinced >>>>>> that it even works right if the user changes mirrors after being sent >>>>>> to the site page. >>>>> >>>>> Would it make more sense to drop to the package chooser page, after >>>>> issuing the >>>>> error message and advising the user to: select Back to go to the >>>>> package chooser >>>>> page, select Next to retry the downloads, or select Cancel to exit? >>>> >>>> Do we actually report the package name for the failed download so >>>> that the >>>> user could make an informed change in the package chooser? >>> >>> No.  Currently the only way for the user to find out is to finish the >>> setup run >>> and then look at the log.  There's been a FIXME about this at the end of >>> download.cc:download_one() since 2001.  Maybe it's time to fix this. >>> We could >>> simply keep a list of packages (or files?) for which the download >>> failed, and >>> then report this in the "Download incomplete" dialog. > > Note that in the pathological case of a mirror which only has a > setup.ini, the list of failed packages could be very large. I guess we should limit the number of failed packages that we report. Alternatively, we could make it a fatal error if there are too many, and refer the user to the log for the full list. I'm working on a patch. Ken