[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 [EMAIL PROTECTED]