This is the mail archive of the
mailing list for the Cygwin project.
Re: setup -g ???
On 14/03/2018 15:26, David Allsopp wrote:
[reformatted for top-posting]
---------- 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 <email@example.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
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 .
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
(For example, some packages now exist (e.g. vim ), 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.
So, yes, if you are using --packages, you should continue to use -g
(unless you know what you are doing and/or like to live dangerously)
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple