From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96226 invoked by alias); 23 Apr 2018 20:46: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 94305 invoked by uid 89); 23 Apr 2018 20:45:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,SPF_HELO_PASS,SPF_PASS,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=lee, Lee, integration, brown 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; Mon, 23 Apr 2018 20:45:36 +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 w3NKjOKR003334 for ; Mon, 23 Apr 2018 16:45:25 -0400 Received: from [10.128.130.236] (dhcp-gs-748.eduroam.cornell.edu [10.128.130.236]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id w3NKjNcr012791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 23 Apr 2018 16:45:24 -0400 Subject: Re: setup -g ??? To: cygwin-apps@cygwin.com References: <15aa3220-c49d-9de9-3147-e817951fa88f@cornell.edu> From: Ken Brown Message-ID: <88194bb6-aa01-df0f-75f1-7a070d649ca9@cornell.edu> Date: Mon, 23 Apr 2018 20:46:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <15aa3220-c49d-9de9-3147-e817951fa88f@cornell.edu> 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: 2018-04/txt/msg00033.txt.bz2 On 4/2/2018 1:03 PM, Ken Brown wrote: > [Redirected to cygwin-apps from > https://cygwin.com/ml/cygwin/2018-03/msg00365.html.] > > On 3/22/2018 6:46 PM, Jon Turney wrote: >> On 14/03/2018 15:26, David Allsopp wrote: >>> [reformatted for top-posting] >>> >>> Lee wrote: >>>>> ---------- Forwarded message ---------- >>>>> From: Jon Turney >>>>> Date: Fri, 3 Nov 2017 15:26:27 +0000 >>>>> Subject: Re: Problem running the latest python2-2.7.14-1 under >>>>> AppVeyor >>>>> To: The Cygwin Mailing List >>>>> >>>>> On 03/11/2017 14:45, Vadim Zeitlin wrote: >>>>>> Our build has started on AppVeyor, a continuous integration provider, >>>>>> started failing since a couple of days as a makefile command >>>>>> running a >>>>>> Python script started failing with exit code 127 without any more >>>>>> information. This is a strange situation as I can't reproduce the >>>>>> problem locally, but something definitely seems to be wrong with this >>>>>> package on the AppVeyor machine as Python just doesn't seem to be >>>>>> executable, e.g. the output of these commands in our batch file >>>>> driving the build: >>>>> >>>>> Perhaps you need to provide the -g (--upgrade-also) flag to cygwin's >>>>> setup. >>>>> >>>>> Due to setup terribleness, without this flag, it will install the >>>>> requested packages, and any missing dependencies of them, but not >>>>> upgrade any of the dependencies which are already installed to the >>>>> current (and perhaps needed) version... >>>>> >>>>> See also [1]. >>>>> >>>>> [1] https://sourceware.org/ml/cygwin/2017-03/msg00365.html >>>> >>>> Should we still be using the -g (--upgrade-also) flag on setup? >>> >>> I believe so (or at least hope so). I think it's the case that setup >>> should now know to upgrade a dependency if you install a new package >>> which requires a newer version of it, but I hope that's not become >>> the same as setup effectively acting with --upgrade-also every time >>> you run it (that would be a real nuisance, unless the entire Cygwin >>> package universe is going to be recompiled on every new Cygwin release). >> >> This is basically correct. >> >> setup is now capable of being told about dependencies where upgrading >> an already installed package is required, but this information isn't >> currently collected >> >> (For example, some packages now exist (e.g. vim [1]), which were built >> with gcc 6.4.0-5 and cygport 0.31.0-1.  These packages almost >> certainly use ssp/fortify functions in the cygwin DLL, and so require >> a cygwin package >=2.10.0-1 (technically, the requirement is cygwin >> API >=0.320), but the dependency recorded is only on the cygwin >> package at any version) >> >> That's something someone could usefully work on, if they were so >> inclined. > > The attached cygport patch attempts to address this by requiring, for > each dependency of a package, a version >= the version installed at the > time the package was built.  It treats only dependencies found by > cygport, not those added via REQUIRES in the cygport file.  My thinking > is that the cygport user should be in control of added dependencies; > s/he can add version numbers if desired. > > mksetupini would need to be updated to parse versioned dependencies. (Or > maybe it's expecting a different syntax; I didn't check.) I finally got around to checking this, and it seems that mksetupini already recognizes dependencies with version relations, provided that the hint file uses "depends:" instead of "requires:". Unfortunately, changing cygport to use "depends:" instead of "requires:" might confuse maintainers, given that cygport files currently use "DEPEND" for build dependencies. An alternative would be for cygport to start using commas rather than spaces to separate dependencies. mksetupini could then parse "requires:" the same way it now parses "depends:" if it finds commas in the "requires:" list. Ken