From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63532 invoked by alias); 9 Jan 2018 15:37:28 -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 63414 invoked by uid 89); 9 Jan 2018 15:37:27 -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=Hx-languages-length:2743, transaction, our, HContent-Transfer-Encoding:8bit X-HELO: limerock02.mail.cornell.edu Received: from limerock02.mail.cornell.edu (HELO limerock02.mail.cornell.edu) (128.84.13.242) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Jan 2018 15:37:25 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id w09FbNF4028471 for ; Tue, 9 Jan 2018 10:37:23 -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 w09FbMco024377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 9 Jan 2018 10:37:22 -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> <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> From: Ken Brown Message-ID: Date: Tue, 09 Jan 2018 15: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: <87e4ba12-ed92-1959-d8ae-ab51986f7036@dronecode.org.uk> Content-Type: text/plain; charset=utf-8; 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/msg00016.txt.bz2 On 1/9/2018 8:25 AM, Jon Turney wrote: > On 24/12/2017 15:00, Ken Brown wrote: >> On 12/13/2017 5:31 PM, Ken Brown wrote: >>> On 12/13/2017 1:05 PM, Achim Gratz wrote: >>>> Ken Brown writes: >>>>> 1. Uninstall A. >>>>> 2. Don't uninstall B. >>>>> >>>>> On the surface, it would seem that libsolv chose 2 by default, because >>>>> it returned an empty transaction list.  This was reflected in the log >>>>> and was also clear when I selected 'Back'. > > Yeah, I think what is actually happening here is that the solver returns > a partial solution, without the problematic transaction. > > But yeah, there's no real concept of a default solution, so (lacking a > UI to choose, which I think is a bit out of scope for the moment), it's > up to us to define one. > >>>> I don't think there is a default in this case.  I also see in zypper >>>> that the order of the proposed solutions (there can be way more than >>>> two >>>> if the dependencies are more complicated) is not always the same, so >>>> there is no preference implied by the order as well. >>>> >>>>> Maybe we have to deal with this situation ourselves.  Whenever a >>>>> problem involves a missing dependency, we could choose as default >>>>> solution the one that installs/keeps the dependent package, as is >>>>> currently done. >>>> >>>> That solution unfortunately isn't always the one that causes the least >>>> amount of transactions or even the least amount of breakage. >>> >>> That may be true, but I still think it's a reasonable default.  The >>> user doesn't have to accept it.  Also, it's consistent with what >>> setup currently does, so it won't surprise anyone. >>> >>> The attached patch attempts to implement my suggestion. > > I came up with a slightly different solution of just picking the first > solution as a default. That's certainly easier than what I was trying to do. If we do that, we should probably change the UI to remove the implication that the default solution is recommended. For example, if A requires B and the user tries to uninstall B, the first solution seems to usually (always?) be "uninstall A". This may or may not be what the user wants. Maybe we should say something like, "By default, the first proposed solution will be selected for each problem. If this is not what you want, press Back...." > After solving problems we also need to consider the 'install source for > everything I install' flag, which unfortunately requires quite a bit of > refactoring. > > See attached. I just did a quick test, trying to uninstall B in the situation above, and it didn't work as expected. Even though "Uninstall A" was the first solution, A didn't get uninstalled. Ken