This is the mail archive of the
mailing list for the Cygwin project.
Re: Please try new setup exe's
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 22 Jul 2013 01:59:57 -0400
- Subject: Re: Please try new setup exe's
- References: <20130715170553 dot GA6166 at ednor dot casa dot cgf dot cx> <51E89D46 dot 1010001 at shaddybaddah dot name> <20130719091510 dot GE30542 at calimero dot vinschen dot de>
- Reply-to: cygwin-apps at cygwin dot com
On Fri, Jul 19, 2013 at 11:15:10AM +0200, Corinna Vinschen wrote:
>On Jul 19 11:58, Shaddy Baddah wrote:
>> On 16 Jul 2013 03:05+1000, Christopher Faylor wrote:
>> >I'd appreciate it if people could try the two new setup.exe's
>> >installed at http://cygwin.com/
>> >http://cygwin.com/setup-x86.exe for 32-bit
>> This is not working for me against an existing install, where I am
>> following a two-step process to install.
>> That being, Download Without Installing first. To a completely wiped
>> download directory (wiped when I ran into a similar problem on first
>> Then separate run to Install from Local Directory.
>> The problem I encounter is that the new packages selected during the
>> Download step, do not appear when I try to perform the Install.
>> Rather at the Install step, as expected, I get an immaculate list of
>> packages currently installed.
>> PS: in the first attempt, the packages downloaded did appear for
>> selection and install. However, I encountered a error that was
>> something like '(null) on reading file' and the installation did not
>> I wiped the download directory because I felt certain it was picking up
>> the package availability from release directories downloaded by
>> setup.exe. And was then looking for the actual package file in the new
>> (offset by the x86 prefix) release directory.
>> The changed behaviour seems to give affirmation to that.
>I just tried it myself, and the behaviour is weird. I always install
>from a local mirror, and this still works as expected with the new
>setup binaries. The directory structure created by setup's "Download
>only" is identical to the layout of a mirror. Setup also picks up the
>right setup.ini file, but then it presents an empty update list. The
>ini file is correct, the newer packages have been downloaded. If you
>then click through the available versions, the new version is not
>shown at all.
>I tried with the run2 package. Installed version is 0.4.2-1, new
>version is 0.4.2-2. Both packages have been downloaded. The update
>view shows "Nothing to install/update". The full view shows the run2
>package, installed version 0.4.2-1, choices are "Keep" and "Uninstall".
This should be fixed in the current versions of
The problem was that the arch directory was getting added to the path
twice, causing setup.exe to look for <mirrordir>/x86/x86/... When it
couldn't find the package in that path, the referenced package from
setup.ini was deleted from its internal database.
It is a sad commentary that I couldn't find the place where setup.exe
checks for the on-disk existence of these packages. I resisted the urge
to run Process Explorer for some time, assuming that I'd eventually
figure out where to set a breakpoint. When I gave up and ran Process
Explorer, it showed the erroneous file accesses and the problem was
At least I now have a clearer idea where to make modifications to get
rid of the url-munged directory stuff. I guess that's a good thing.