From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63041 invoked by alias); 5 Dec 2017 17:36:38 -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 63020 invoked by uid 89); 5 Dec 2017 17:36:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:2027, offer, click, our 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; Tue, 05 Dec 2017 17:36:36 +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 vB5HaYK5014053 for ; Tue, 5 Dec 2017 12:36:35 -0500 Received: from [192.168.0.4] (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 vB5HaX1O001017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 5 Dec 2017 12:36:34 -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> <488ba627-de58-ddc7-7f69-696adae76b8a@cornell.edu> <7a173f99-a2e1-a07c-a9df-5bebcf377957@cornell.edu> <87poau9znx.fsf@Rainer.invalid> <050204e5-0ed3-8e47-3825-58ec6a10f44f@cornell.edu> <87ingltcn0.fsf@Rainer.invalid> <4ed6c549-dddd-fc45-3ed8-f7339548d7cd@cornell.edu> From: Ken Brown Message-ID: <8b645a2a-baea-2c3c-65a3-53da0e8586a4@cornell.edu> Date: Tue, 05 Dec 2017 17:36:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: 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-12/txt/msg00025.txt.bz2 On 12/5/2017 9:32 AM, Jon Turney wrote: > On 14/09/2017 21:46, Ken Brown wrote: >> On 9/14/2017 1:26 PM, Achim Gratz wrote: >>> Ken Brown writes: >>>> What I've been struggling with, however, is the UI.  But now that I >>>> think about it, maybe it isn't that hard.  It's just a matter of doing >>>> something reasonable if the user unchecks "Accept default problem >>>> solutions".  I'll see what I can come up with. >>> >>> Well, zypper pretty much just gives you a bunch of possible solutions >>> and asks you to select one if there is either more than one or the >>> otherwise preferred solution is blocked by a lock.  There is always one >>> "break package by doing " down that list.  You could >>> maybe offer something along those lines in the inevitable dialog box? >> >> In the long run I think that's the way to go.  But implementing that >> is more work than I feel like doing at the moment.  For now I've gone >> with an approach that was easier to program, more like the current >> setup.exe.   If the solver finds problems (including missing >> dependencies), the user has four choices on the Prerequisite page: >> >> 1. Click Back to go back to the Chooser page, with the Pending view >> showing the solver's default solutions. >> >> 2. Click Next to accept the default solutions. > > Doing some testing of per-version requires, I've been looking at this > page quite a bit. > > It seems we're missing something to actually apply the default solution, > so "accept default solutions" makes no changes, at the moment. (looks > like we have to do this ourselves with solver_take_solution() ?) I'm not sure. I thought at some point I saw "accept default solutions" do something, but there have been a lot of changes since then. > Also, in the dependency problem report, we should identify which of the > possible solutions is the default one, so it's clearer what "accept > default solutions" is going to do. Agreed. Ken