setup -g ???

[Ken Brown]

On 4/23/2018 4:45 PM, Ken Brown wrote:
> 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 <cygwin@cygwin.com>
>>>>>>
>>>>>> 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:".

I've just sent a patch series that does this, among other things.

Ken