This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] setup: Handle the package validation exception
- From: "Iain Alexander" <ia at stryx dot demon dot co dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Wed, 01 Feb 2006 23:36:34 -0000
- Subject: Re: [PATCH] setup: Handle the package validation exception
On 31 Jan 2006 at 9:46, Igor Peshansky wrote:
> On Mon, 23 Jan 2006, Igor Peshansky wrote:
>
> > In the scenarios you've given above, if network install is selected and
> > the locally cached copy is corrupt, it will be re-downloaded. In case of
> > local install, the corrupt copy will result in the same behavior as not
> > having the package on your machine. Frankly, I fail to see the problem...
> > Perhaps I'm missing something.
>
> Ping?
I originally responded to this privately, since I wasn't on cygwin-apps at the time,
and later moved back to cygwin-apps as follows:
Subject: Re: Cygwin Setup: Fatal Error: Uncaught Exception
Date: Thu, 26 Jan 2006 22:53:19 -0000
[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