Re: [PATCH] setup: Handle the package validation exception

[Brian Dessent <brian at dessent dot net>]

Igor Peshansky wrote:

> Well, let's look at it this way: if we are downloading, that's exactly the
> behavior we want -- pretend the corrupted cached version doesn't exist and
> re-download it.  If we're installing from the local directory, then we
> cannot install the corrupted packages anyway, so they might as well not
> exist.  Sounds to me like ignoring a corrupted version is the right course
> of action in any case.
> 
> In fact, why should the user even care that their local version is
> corrupted?  All they should know is whether it's available to be installed
> (when doing a local install).  And for network installs, caching should be
> transparent anyway.  For power users, we can add some logging on corrupted
> packages.

The problem as I see it is that if somebody is doing a "install from
local directory" and they have a bad package, it will be silently
ignored.  So they will not know that it needs to be deleted,
redownloaded, etc.  It will just be gone from the list of available
packages, potentially in a confusing way, for example:

"I installed 'foo' but it doesn't work!" -- 'bar' was a dependency of
'foo' but because it was an invalid package 'bar' was ignored.

"I updated my cygwin distro but the problem persists" -- because the
local copy of 'foo' package had the wrong md5, so it wasn't upgraded.

"I'm looking for libfoo but it's not on the list"
"yes it is, just select it"
"no, I don't see it"
"are you sure, you might have to swtich to 'full'"
(34 further messages exchanged trying to diagnose)
"Oh, my downloaded copy was the wrong size and needed to be deleted and
redownloaded."

In all these cases the user needs to know that there is something wrong
with their local copy of the package, so that they can delete or
redownload it.  If we silently pretend it doesn't exist then all kinds
of hard-to-diagnose scenarios come to mind.

Brian