Re: setup -g ???

[Ken Brown <kbrown at cornell dot edu>]

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