This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Cygwin Setup: Fatal Error: Uncaught Exception
- From: "Iain Alexander" <ia at stryx dot demon dot co dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 26 Jan 2006 22:53:19 -0000
- Subject: Re: Cygwin Setup: Fatal Error: Uncaught Exception
- References: <43D69F92.3803.2565631@ia.stryx.demon.co.uk>
[Moving to cygwin-apps from private e-mail]
On 24 Jan 2006 at 17:11, Igor Peshansky wrote:
> On Tue, 24 Jan 2006, Iain Alexander wrote:
>
[snip]
> > Whether treating the package as missing is the right long-term answer is
> > more complicated.
> >
[snip]
> > Briefly, re-downloading the package may be futile, since the problem
> > could just as easily be an old bogus setup.ini from a different mirror,
> > as it was in my case.
>
> Perhaps we *should* continue this on-list. If you post the above
> statement, I'll reply there. My argument still applies, though -- if you
> are installing from the local directory, whatever setup.ini you have is
> the ultimate authority; if it says the package is corrupted, setup has no
> way of checking it. If you're either downloading or installing from the
> net, setup.ini's should have been updated. If setup uses a stale
> setup.ini whenever it cannot find one on the mirror, that's a separate bug
> that should be fixed.
> Igor
I think there's some misunderstanding in one or both directions getting in the way here, so
let's start this again.
The symptoms are that during local install, a package fails validation because the file from
mirror Y has a different size/checksum from that specified in the setup.ini from mirror X
(although it matches that in the setup.ini from mirror Y). I can repeat this at will here. I think
I can enable you to reproduce this behaviour, but I'm not 100% sure - in my case mirror X is
the first setup.ini it reads.
If this is a design feature, then I stand by what I said above, and continue as follows.
<feature>
Unfortunately, it's not as simple as that. There's a local setup.ini for each mirror you've ever
used, four in my case. At least two of those mirrors no longer exist, so the setup.ini will
never be updated. I can see that there are reasons for keeping those around, since I could
have packages downloaded but not installed in any of them.
I haven't got deeply enough into the code to be 100% sure of all the details. But it seems to
me that setup.exe (local install) reads all the local <setup.ini>s, since they may have
information about different versions of packages, but basically assumes that they are all
consistent, so when it needs to confirm a size/checksum, it looks in the first source it finds. I
don't know how easy it would be to look in the source corresponding to the package
location, which would be the most consistent thing to do.
</feature>
However if the behaviour described above is a bug, as I'm coming to believe (again), then
that's a completely different situation. If we always validate against the setup.ini from the
*same* mirror, then a mismatch can (and can only) be fixed by a repeat download of
setup.ini and/or the package file, so treating the package as missing is appropriate. Then
all we have to do is track down and fix the bug.
--
Iain Alexander ia@stryx.demon.co.uk