From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49711 invoked by alias); 14 Jan 2018 02:37:50 -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 49693 invoked by uid 89); 14 Jan 2018 02:37:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=messaging, offer, alternatives X-HELO: limerock04.mail.cornell.edu Received: from limerock04.mail.cornell.edu (HELO limerock04.mail.cornell.edu) (128.84.13.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 14 Jan 2018 02:37:46 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock04.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id w0E2bi2u003310 for ; Sat, 13 Jan 2018 21:37:44 -0500 Received: from [10.13.22.4] (65-112-130-194.dia.static.qwest.net [65.112.130.194]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id w0E2bgtV024386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 13 Jan 2018 21:37:43 -0500 Subject: Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP) To: cygwin-apps@cygwin.com References: <20170531105015.162228-1-jon.turney@dronecode.org.uk> <87poau9znx.fsf@Rainer.invalid> <050204e5-0ed3-8e47-3825-58ec6a10f44f@cornell.edu> <87ingltcn0.fsf@Rainer.invalid> <4ed6c549-dddd-fc45-3ed8-f7339548d7cd@cornell.edu> <1ec0f4de-380f-c6d1-59e7-03570f36b80b@cornell.edu> <87609alczj.fsf@Rainer.invalid> <31df6cf0-1abd-9cb0-a5c3-3c2b0a7d069c@cornell.edu> <87e4ba12-ed92-1959-d8ae-ab51986f7036@dronecode.org.uk> <79d71e69-57a9-8303-79c8-ba2bfdd098d8@cornell.edu> <1ecbad19-013e-6cf2-7dd8-019f72f7be3b@cornell.edu> <9ebf0e53-c87e-30f7-114f-a0456004b847@SystematicSw.ab.ca> <032b0ecf-744d-b1bf-00c5-d3adaa2a4a02@cornell.edu> <7a9e6a78-7342-063f-8c4b-a4b205fccf16@SystematicSw.ab.ca> From: Ken Brown Message-ID: <2c34c4d1-55cd-33a6-405c-f07e1350227a@cornell.edu> Date: Sun, 14 Jan 2018 02:37:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <7a9e6a78-7342-063f-8c4b-a4b205fccf16@SystematicSw.ab.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Cornell-Gauge: Gauge=X X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00046.txt.bz2 On 1/13/2018 8:52 PM, Brian Inglis wrote: > On 2018-01-13 17:00, Ken Brown wrote: >> On 1/13/2018 5:55 PM, Ken Brown wrote: >>> On 1/13/2018 4:29 PM, Brian Inglis wrote: >>>> On 2018-01-13 12:56, Ken Brown wrote: >>>>> 2. We should probably remove, or at least reword, the dire warning about >>>>> accepting the default solutions.  I'm not sure we want to "strongly recommend" >>>>> the default solution over the other solution(s).  I guess what we really >>>>> want to >>>>> say is that we strongly recommend resolving the problems before continuing. >>>> >>>> For users who only run setup and use programs, a dire warning and strong >>>> recommendations are appropriate. >>>> >>>> Alternatives are to also remove all packages dependent on the package to be >>>> removed, or lastly, to remove only the requested package, leaving the >>>> installation inconsistent. Those alternatives would have to be presented to the >>>> user for selection, then executed. >>>> >>>> Anything else requiring the user to resolve would require a FAQ entry explaining >>>> what that meant, what diagnosis and actions would be required, and that would >>>> probably generate emails from users asking what they should do. >>>> >>>> Better to allow the solver to resolve issues and just let users choose >>>> straightforward alternatives, with the view of trying to keep the installation >>>> consistent, unless explicitly overridden, such as to test an alternative >>>> implementation of a dependency installed outside of setup. >>> >>> The current situation on the topic/libsolv branch is the following. Suppose A >>> requires B and the user asks to uninstall B.  They will get a problem report >>> showing two possible solutions: >>> >>> 1. Uninstall A. >>> 2. (default) Don't uninstall B. >>> >>> If they uncheck 'Accept default solutions' and select 'Next', they'll get a >>> warning that says "We strongly recommend that you accept the default >>> solutions.  Some packages may not work properly if you don't. Are you sure you >>> want to proceed?" >>> >>> This is misleading insofar as it implies that something bad will happen if the >>> user prefers to solve the problem by uninstalling A.  What is true is that >>> some packages may not work properly if the user answers 'Yes'. >>> >>> I think we should be able to find wording that is accurate while still making >>> it clear that we recommend going back and fixing the problem.  I don't yet >>> have a good candidate for that wording. >> >> Something like the attached might do the job. > > Just saying "Unsolved problems" does not tell the user what they did and what > impact it will have, and invites a FAQ entry for Setup - Unsolved problems. "WARNING - Unsolved Problems" is simply the caption on the message box. > Could we please be more explicit in the UI and the logs about the action being > taken and the impact: instead of "Unsolved problems" and "Some packages" maybe > something more like "uninstalling package U will break packages P1...", and We were already explicit when we displayed the prerequisites page with a problem report. There's no need to repeat it. What we're discussing right now is what warning we should give if the user, *after seeing the problem report*, unchecks the 'Accept default solutions' box and selects 'Next'. > instead of "default solutions" maybe something more like "recommended actions"? I've already explained why I think it would be misleading to say "recommended" rather than "default". In the scenario above with packages A and B, the user may be trying to pare down their installation by uninstalling some packages. They try to uninstall B, we warn them that this will break A, and we offer them two possible solutions. It's perfectly reasonable for us to present "Keep B" as the default solution, especially since, as Jon pointed out, that's what we currently do. But I don't think it's reasonable for us to *recommend* keeping B without knowing what the user wanted to accomplish. Maybe uninstalling A better fits their needs. > That shows and records the action and impact for diagnosis and remediation when > users do something unintended and need to undo it, changing the messaging from > the implementation model to the user's model, and giving users and maintainers > enough information to diagnose what will or did happen, and how to undo that. The current code in the topic/libsolv branch already does this. Maybe it could do it better. It would be great if you would test it and suggest improvements. Ken