From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5385 invoked by alias); 17 Sep 2017 16:02:47 -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 5365 invoked by uid 89); 17 Sep 2017 16:02:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=worrying, our, HContent-Transfer-Encoding:8bit X-HELO: limerock01.mail.cornell.edu Received: from limerock01.mail.cornell.edu (HELO limerock01.mail.cornell.edu) (128.84.13.241) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 17 Sep 2017 16:02:44 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id v8HG2g8w008205 for ; Sun, 17 Sep 2017 12:02:43 -0400 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 v8HG2fOZ019081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 17 Sep 2017 12:02:42 -0400 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> <9bcf50cf-81bc-c9d1-3ac3-b7e1a3522045@dronecode.org.uk> <5441628f-a99a-1611-616a-da98ea9a0e12@cornell.edu> <3c54d477-a4a4-1a87-e623-14d0279897ce@gmail.com> From: Ken Brown Message-ID: <6979ecca-8ccd-704d-f84b-1579a4fd7f1c@cornell.edu> Date: Sun, 17 Sep 2017 16:02: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: <3c54d477-a4a4-1a87-e623-14d0279897ce@gmail.com> 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-09/txt/msg00029.txt.bz2 On 9/15/2017 4:56 PM, cyg Simple wrote: > On 9/15/2017 12:53 PM, 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. >> >> Anyway, as I said, I've already disabled the use of >> PrereqChecker::upgrade.  More precisely, I've changed >> SolverSolution::update so that it never sends SOLVER_UPDATE | >> SOLVER_SOLVABLE_ALL.  As a result, PrereqChecker::upgrade is simply >> ignored, and everything seems to be working OK. >> > > Since this discussion appears to resolve around "test" versus > "production" releases No, it's simply a technical discussion about a new implementation of setup's dependency checker. > would it not be better served if there were two > differing base paths, one for production and one for test? If that > occurred then there may be more testers as what is used for production > isn't borked by a test version of some package or even Cygwin itself. > > So for example C:\cygwin64 serves the production path while > C:\cygwin64test serves the test path. This would help segregate test > from a production environment without worrying the user with needing to > revert back if something fails. I'm not sure what you're suggesting. Anyone is free to create two different Cygwin installations and use one of them for testing. In fact, I do that all the time. But I don't see that this is something for setup to manage. Ken