From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27173 invoked by alias); 15 Sep 2017 19:24:51 -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 27160 invoked by uid 89); 15 Sep 2017 19:24:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Wire, Hx-languages-length:2894, offer, wire X-HELO: out4-smtp.messagingengine.com Received: from out4-smtp.messagingengine.com (HELO out4-smtp.messagingengine.com) (66.111.4.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Sep 2017 19:24:49 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6483120BF1 for ; Fri, 15 Sep 2017 15:24:47 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 15 Sep 2017 15:24:47 -0400 X-ME-Sender: Received: from [192.168.1.102] (host31-51-205-109.range31-51.btcentralplus.com [31.51.205.109]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A00024B4C for ; Fri, 15 Sep 2017 15:24:47 -0400 (EDT) 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: Jon Turney Message-ID: Date: Fri, 15 Sep 2017 19:24:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <4ed6c549-dddd-fc45-3ed8-f7339548d7cd@cornell.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-09/txt/msg00023.txt.bz2 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 Yeah, a better interface to the solution list would be nice, but :effort: and it's unclear how much use it would get with the loose requirements our current package database contains. I'm not sure there is huge value in the current "don't install dependencies" option. I don't know why anyone would want to do that, and it's just going to give you a broken install sometimes... > 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. > > 3. Uncheck the "Accept default solutions" box and click Next.  If the > user dismisses the resulting warning, setup will go ahead and do what > the user requested. > > 4. Cancel. > > Once the inevitable remaining bugs are fixed, I think we'll have a > setup.exe that's better than the current one, with possibilities for > further UI improvements along the lines you suggested. Thanks again for your work on this. Can you rebase your and my patches onto master, and push to sourceware in a topic/libsolv branch? After that, I think it might be useful to make a binary available for wider testing. Two things I have left to look at: - Since the distributed setup is cross-built on Linux, I need to look into making a RPM for the cross-built libsolv. - Wire up the "Source:" (note capital 'S') lines in setup.ini. These work in current setup versions (although we don't use it, but I'd like to change that). Since the the source package might appear after the package in setup.ini, this seems to conflict with the current approach of storing the sourcepackage solvable id, which I did because searching the solver repo for a package by name was slow. With hindsight, this seems wrong.