From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70314 invoked by alias); 26 Sep 2017 14:50:23 -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 70303 invoked by uid 89); 26 Sep 2017 14:50:23 -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=arranged, sigh, our, Hx-spam-relays-external:ESMTPA X-HELO: out2-smtp.messagingengine.com Received: from out2-smtp.messagingengine.com (HELO out2-smtp.messagingengine.com) (66.111.4.26) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Sep 2017 14:50:18 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A15E120D4A; Tue, 26 Sep 2017 10:50:16 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Tue, 26 Sep 2017 10:50:16 -0400 X-ME-Sender: Received: from [192.168.1.102] (host86-141-130-248.range86-141.btcentralplus.com [86.141.130.248]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F5972444E; Tue, 26 Sep 2017 10:50:16 -0400 (EDT) Subject: Re: [PATCH setup 00/14] Use libsolv, solve all our problems... (WIP) To: Ken Brown , cygwin-apps@cygwin.com References: <20170531105015.162228-1-jon.turney@dronecode.org.uk> <488ba627-de58-ddc7-7f69-696adae76b8a@cornell.edu> <9bcf50cf-81bc-c9d1-3ac3-b7e1a3522045@dronecode.org.uk> <5441628f-a99a-1611-616a-da98ea9a0e12@cornell.edu> From: Jon Turney Message-ID: Date: Tue, 26 Sep 2017 14:50: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: <5441628f-a99a-1611-616a-da98ea9a0e12@cornell.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-09/txt/msg00049.txt.bz2 On 15/09/2017 17:53, Ken Brown wrote: > On 9/15/2017 11:15 AM, Jon Turney wrote: >> On 08/09/2017 19:54, Ken Brown wrote: >>> Finally, I have a question for you, Jon: You introduced >>> PrereqChecker::upgrade, which is true if and only if the user selects >>> Current or Test.  I don't see why this is needed.  I've disabled the >>> use of it and haven't noticed any ill effects.  Am I missing something? >> >> This is supposed to be passed into SolverSolution::update() and used >> to determine if a SOLVER_UPDATE | SOLVER_SOLVABLE_ALL task is given to >> the solver, causing all packages to be updated (if possible) (i.e. so >> 'Keep' doesn't update anything) > > I've already arranged (by using SOLVER_LOCK) that 'Keep' doesn't update > anything.  So I don't think we need to worry about that case.  On the > other hand, if 'Current' or 'Test' is selected, then we already upgrade > as appropriate in the task list sent to the solver, so I don't think > it's necessary to send SOLVER_UPDATE | SOLVER_SOLVABLE_ALL to the solver > in that case either. Yeah, I see. Sigh. If we select 'curr', then the latest version of all installed packages is selected by the picker and will be shown in the pending view, and gets fed into the solver. I guess this is technically wrong: really we should ask the solver to do SOLVER_UPDATE | SOLVER_SOLVABLE_ALL, which will come up with a solution which updates all installed packages to the latest possible version, subject to any other constraints which exist. I suspect there's no difference between these two at the moment, though. Not sure how to do this properly, though.