From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92755 invoked by alias); 24 Oct 2017 20:25:06 -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 92743 invoked by uid 89); 24 Oct 2017 20:25:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= 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; Tue, 24 Oct 2017 20:25:04 +0000 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite4.serverfarm.cornell.edu [10.16.197.9]) by limerock04.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id v9OKP171029170 for ; Tue, 24 Oct 2017 16:25:01 -0400 Received: from [172.16.255.77] (74-5-253-222.wan.centurylinkservices.net [74.5.253.222] (may be forged)) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id v9OKOxLf025768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 24 Oct 2017 16:25:01 -0400 Subject: Re: [setup topic/libsolv] Does "obsoletes:" work? To: cygwin-apps@cygwin.com References: <8344e55f-2036-187b-7cb9-819d2cdb0e99@cornell.edu> <2ec4937d-5932-a47a-964d-b3fc8c030da3@cornell.edu> From: Ken Brown Message-ID: <47d9f129-3c05-821e-56af-177bab31c355@cornell.edu> Date: Tue, 24 Oct 2017 20:25:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: 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: 2017-10/txt/msg00115.txt.bz2 On 10/24/2017 4:09 PM, Jon Turney wrote: > On 23/10/2017 18:43, Ken Brown wrote: >> On 10/23/2017 7:38 AM, Jon Turney wrote: >>> On 21/10/2017 21:18, Ken Brown wrote: >>>> On 10/20/2017 6:24 PM, Ken Brown wrote: >>>>> Have you ever tested the "obsoletes:" feature of setup/libsolv?  I >>>>> tried adding an "obsoletes:" line to setup.ini, and it didn't seem >>>>> to have any effect. >>> >>> It seems I tested it back in May, so it might well have broken since :) >>> >>> Here's a very small test repo I've been using for some tests: >>> http://www.dronecode.org.uk/cygwin/test/x86_64/ >>> >>> But yes, your patch looks like it's needed for it to work correctly... >>> >>>> It turns out that it *is* working (after a minor fix, attached), but >>>> not always as I expect.  Suppose A requires B and C obsoletes B. >>>> Then the "obsoletes" statement appears to have no effect.  If I >>>> remove the dependence of A on B, then setup does propose >>>> uninstalling B and installing C. >>>> >>>> I guess the issue is that libsolv interprets "C obsoletes B" as >>>> "uninstall B and install C", and it won't uninstall B while >>>> something requires it. >>> >>> The 'targeted' vs. 'untargeted' distinction is relevant here? Perhaps >>> we are doing the wrong one? >> >> Maybe.  I've read and re-read the discussion of this in >> libsolv-bindings.txt, and I'm still not sure I understand it. > > Yeah, the documentation is a bit impenetrable. > >> But here's a simpler case where "obsoletes" isn't working as I expect. >> Using your test repo, in which A requires C and obsoletes B, I start >> with none of the packages installed.  I choose B for installation >> (either interactively or on the command line), and B gets installed. >> If I now run setup a second time, A and C get installed and B gets >> uninstalled. >> >> I expected A and C to be installed on the first run.  I don't think >> this has anything to do with targeted vs. untargeted, because that >> distinction is only relevant for updating installed packages. > > I guess I had the opposite expectation (if I ask for A to be installed, > that's what should happen, because if it insists on upgrading it behind > my back there's no way to do that...) > > The actual behaviour you mention fits what's described there pretty well. OK, so maybe there's no real problem here. In any case, the situation is unlikely to happen often -- the user has to intentionally choose to install an obsolete package. I think we might have reached the point where more widespread testing would be useful. If it would help, I could put together a patch series containing the various (sometimes revised) patches we've discussed recently. Ken