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: [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



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