This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Please try new setup exe's

On Fri, Jul 19, 2013 at 11:15:10AM +0200, Corinna Vinschen wrote:
>On Jul 19 11:58, Shaddy Baddah wrote:
>> Hi,
>> 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
>> >
>> > 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
>> attempt).
>> 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
>> occur.
>> 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*.exe .

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]