From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105953 invoked by alias); 23 Jun 2018 15:10:00 -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 105933 invoked by uid 89); 23 Jun 2018 15:09:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=EOF, recipe, mkdir, cygwin-apps X-HELO: limerock04.mail.cornell.edu Received: from limerock04.mail.cornell.edu (HELO limerock04.mail.cornell.edu) (128.84.13.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 23 Jun 2018 15:09:58 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock04.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id w5NF9ucI020633 for ; Sat, 23 Jun 2018 11:09:56 -0400 Received: from [192.168.0.15] (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 w5NF9suo001474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 23 Jun 2018 11:09:55 -0400 Subject: Re: [PATCH setup] Finish providing support for provides: and conflicts: To: cygwin-apps@cygwin.com References: <20180321193807.11744-1-kbrown@cornell.edu> <6fb8aceb-7a04-36e8-c14f-4d182bd27e1e@dronecode.org.uk> From: Ken Brown Message-ID: <220ce253-6dcb-18fd-fcfd-cca3b2aca517@cornell.edu> Date: Sat, 23 Jun 2018 15:10:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------214921992E533A8528878C54" X-PMX-Cornell-Gauge: Gauge=XXXXX X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none; X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00026.txt.bz2 This is a multi-part message in MIME format. --------------214921992E533A8528878C54 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-length: 2025 On 6/19/2018 8:43 AM, Ken Brown wrote: > On 6/18/2018 1:49 PM, Ken Brown wrote: >> [Redirecting to cygwin-apps.] >> >> On 6/18/2018 1:32 PM, Jon Turney wrote: >>> On 06/06/2018 21:44, Jon Turney wrote: >>>> On 04/04/2018 14:21, Ken Brown wrote: >>>>> On 3/21/2018 3:38 PM, Ken Brown wrote: >>>>>> Introduce member functions SolvableVersion::provides() and >>>>>> SolvableVersion::conflicts().  This enables packagedb::read() to >>>>>> access provides and conflicts lists from setup.ini. >>>>> >>>>> Ignore this patch.  It breaks libsolv's dependency processing. >>>>> >>>> >>>> Thanks, even if it's not right, I'd completely overlooked the need >>>> for something like this. >>> >>> Do you have any details on what broke with this?  I've been trying it >>> and I don't notice any problems. >> >> No, I'm sorry.  I don't remember, and I didn't keep any notes about it. > > It's coming back to me now.  I think I was testing the following > situation: I created an installed package A that was being updated > (possibly because of a command-line option).  I made A require a version > of a package B higher than the installed version, so that the update of > A should have forced an update of B.  This wasn't working reliably.  And > if I manually chose to keep the installed version of B, libsolv wasn't > reliably reporting a problem. > > I'll try again to reproduce this, but it might be a few days until I can > get to it. Here's a recipe for reproducing the problem: 1. Create a repository with two packages, A and B, and two versions 1-1 and 2-1 of each. Make A-1-1 require B>=1, and make A-2-1 require B>=2. The attached script does all this. 2. Run setup on this repo and install A-1-1 and B-1-1. 3. Run setup again. It will offer to update both A and B. Choose to keep B and press 'Next'. setup built from the current HEAD correctly reports the dependency problem. But if I apply my patch, then setup doesn't report the problem and lets me proceed to update A without updating B. Ken --------------214921992E533A8528878C54 Content-Type: text/plain; charset=UTF-8; name="make_test.sh" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="make_test.sh" Content-length: 1517 IyEvYmluL3NoCmFyY2g9eDg2XzY0Cm1rZGlyIC1wIHRlc3RyZXBvLyR7YXJj aH0vcmVsZWFzZS97QSxCfQpwdXNoZCB0ZXN0cmVwby8ke2FyY2h9L3JlbGVh c2UvQQp0YXIgLUpjZiBBLTEtMS50YXIueHogLS1maWxlcy1mcm9tIC9kZXYv bnVsbAp0YXIgLUpjZiBBLTEtMS1zcmMudGFyLnh6IC0tZmlsZXMtZnJvbSAv ZGV2L251bGwKY2F0ID4gQS0xLTEuaGludCA8PCBFT0YKc2Rlc2M6ICJUZXN0 IHBhY2thZ2UgQSIKbGRlc2M6ICJUZXN0IHBhY2thZ2UgQSIKY2F0ZWdvcnk6 IExpYnMKZGVwZW5kczogQiAoPj0xKQpFT0YKdGFyIC1KY2YgQS0yLTEudGFy Lnh6IC0tZmlsZXMtZnJvbSAvZGV2L251bGwKdGFyIC1KY2YgQS0yLTEtc3Jj LnRhci54eiAtLWZpbGVzLWZyb20gL2Rldi9udWxsCmNhdCA+IEEtMi0xLmhp bnQgPDwgRU9GCnNkZXNjOiAiVGVzdCBwYWNrYWdlIEEiCmxkZXNjOiAiVGVz dCBwYWNrYWdlIEEiCmNhdGVnb3J5OiBMaWJzCmRlcGVuZHM6IEIgKD49MikK RU9GCnBvcGQKcHVzaGQgdGVzdHJlcG8vJHthcmNofS9yZWxlYXNlL0IKdGFy IC1KY2YgQi0xLTEudGFyLnh6IC0tZmlsZXMtZnJvbSAvZGV2L251bGwKdGFy IC1KY2YgQi0xLTEtc3JjLnRhci54eiAtLWZpbGVzLWZyb20gL2Rldi9udWxs CmNhdCA+IEItMS0xLmhpbnQgPDwgRU9GCnNkZXNjOiAiVGVzdCBwYWNrYWdl IEIiCmxkZXNjOiAiVGVzdCBwYWNrYWdlIEIiCmNhdGVnb3J5OiBMaWJzCmRl cGVuZHM6IGN5Z3dpbgpFT0YKdGFyIC1KY2YgQi0yLTEudGFyLnh6IC0tZmls ZXMtZnJvbSAvZGV2L251bGwKdGFyIC1KY2YgQi0yLTEtc3JjLnRhci54eiAt LWZpbGVzLWZyb20gL2Rldi9udWxsCmNhdCA+IEItMi0xLmhpbnQgPDwgRU9G CnNkZXNjOiAiVGVzdCBwYWNrYWdlIEIiCmxkZXNjOiAiVGVzdCBwYWNrYWdl IEIiCmNhdGVnb3J5OiBMaWJzCmRlcGVuZHM6IGN5Z3dpbgpFT0YKcG9wZApj ZCB0ZXN0cmVwbwpta3NldHVwaW5pIC0tYXJjaCAke2FyY2h9IC0taW5pZmls ZT0ke2FyY2h9L3NldHVwLmluaSAtLXJlbGVhc2VhcmVhPS4gXAoJICAgLS1k aXNhYmxlLWNoZWNrPW1pc3NpbmctZGVwZW5kZWQtcGFja2FnZSAKeHogLWMg JHthcmNofS9zZXR1cC5pbmkgPiAke2FyY2h9L3NldHVwLnh6Cg== --------------214921992E533A8528878C54--