Lee wrote: > On 3/14/18, 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). > > So if I run setup and it says there are no pending updates it might be > lying to me? > > I need to run setup -g and only then if there are no pending updates do > I know that my cygwin installation is up to date?
No - the original question here was about running setup with a command line and the --packages argument. If you run setup interactively (with no arguments), you should be told if any packages need upgrading, just as before, without needing -g. My assumption is that the new dependency solver means that installing a package with --packages should install that and upgrade *only* required dependencies, not the entire system. The OP's issue here with AppVeyor is one I see too, because the AppVeyor team are relatively slow to update the Cygwin installation in their images (that's their call, of course). However, I workaround that using a script which installs required packages and then tests a known command from the package with --version - if I get a non-zero exit code, then I know that the package probably depends on a newer Cygwin DLL and the whole system needs upgrading. For example, quoting https://ci.appveyor.com/project/dra27/opam/build/1.0.210/job/21p7e382hp3q9lh7#L11: > Cygwin package patch will be installed > Cygwin package unzip will be installed > Cygwin package vim will be installed > Cygwin package flexdll will be installed << at this point, the script will have run setup with --packages=patch,unzip,vim,flexdll >> > Cygwin Package Information > Package Version > curl 7.56.1-1 > cygwin 2.9.0-3 > diffutils 3.5-2 > flexdll 0.35-2 > gcc-g++ 6.4.0-4 > make 4.2.1-2 > patch 2.7.4-1 > tar 1.29-1 > unzip 6.0-17 > vim 8.0.1567-1 > Cygwin package upgrade required - please go and drink coffee << at this point, the script runs setup a second time with --upgrade-also >> > Cygwin Package Information > Package Version > curl 7.56.1-1 > cygwin 2.10.0-1 > diffutils 3.5-2 > flexdll 0.35-2 > gcc-g++ 6.4.0-5 > make 4.2.1-2 > patch 2.7.4-1 > tar 1.29-1 > unzip 6.0-17 > vim 8.0.1567-1 This build was on March 11th, and the problem package was Vim - the patch, unzip and flexdll packages hadn't been recompiled against Cygwin 2.10 and so could be installed without a full package upgrade. You can see from my message about coffee why I'd care if -g had become the default, because it takes ages to run (obviously), and I don't want my CI slowed down unnecessarily... David
