From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130792 invoked by alias); 15 Sep 2017 20:56:41 -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 130781 invoked by uid 89); 15 Sep 2017 20:56:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*R:U*cygwin-apps, worrying, H*R:D*cygwin.com, our X-HELO: mail-it0-f45.google.com Received: from mail-it0-f45.google.com (HELO mail-it0-f45.google.com) (209.85.214.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Sep 2017 20:56:40 +0000 Received: by mail-it0-f45.google.com with SMTP id d123so3919143ith.3 for ; Fri, 15 Sep 2017 13:56:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:reply-to:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8uc0DNdEceD2rLi6+cGT+FG1TrlsoU/jdv5iA0X0FDw=; b=Wh8Pwgik3ybOxWnqGVLmnyu8oeYw7TUDBZ7pmJrO9CGFjx2Oh/uLp8CWjEGv68wg8O vjOgpT/KrmF52kpk0wzN+Vim8rZlGeM3lflrwbsuGiZQY/hdhTVoHh1gl8XlesW1/cLB f/wLRMqTItZFinFDgNoVwCIQdGZRHnfMnY2Ku0wthiKh+fsq8lrAq8Hrn53IzMbXI/w2 1RZXTQwhV+5bjfvN9DGP6gnKs6NFJRc3w6aWORgL2A/dIq2v89d/4k8BAc3df2EtP0qd aal1WdbobaOdoGIEMRaTSIO6AWQ+MOB7B+y4xOXxQ5Xwui/c5sJRAlnEouhdO5GMo36t Fk9Q== X-Gm-Message-State: AHPjjUgOUKMpKpuinyh1upf7Lof1xhCvDKUk4QpJAY9nB20LratuLlQb PFS4r47kJ5iRWdNr X-Google-Smtp-Source: AOwi7QB6CyPchxkJrRG3MOM3aM9XuMKs+rJLQR/zMnEKdpkfI2XfBMS7Df3bVtuxlFSFSJgyR52cGQ== X-Received: by 10.36.208.132 with SMTP id m126mr4558547itg.130.1505508998273; Fri, 15 Sep 2017 13:56:38 -0700 (PDT) Received: from [192.168.0.6] (d4-50-42-50.try.wideopenwest.com. [50.4.50.42]) by smtp.gmail.com with ESMTPSA id g100sm894276iod.39.2017.09.15.13.56.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Sep 2017 13:56:37 -0700 (PDT) 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> Reply-To: cygwin-apps@cygwin.com From: cyg Simple Message-ID: <3c54d477-a4a4-1a87-e623-14d0279897ce@gmail.com> Date: Fri, 15 Sep 2017 20:56: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 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00024.txt.bz2 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 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. -- cyg Simple