This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [PATCH] setup: Handle the package validation exception
On Mon, 23 Jan 2006, Brian Dessent wrote:
> 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.
I'm not convinced. How is this different from the package not being there
in the first place?
> 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.
Huh? Wouldn't setup complain about that? It will check "foo", and see
that "bar" is a dependency, but "bar" is not selected... There's even a
special screen for that, isn't there?
> "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.
Updated from local directory? Or from the network? If the latter,
wouldn't it be re-downloaded due to the cached check failing? If the
former, again, it's the same as not having it downloaded at all.
> "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.
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.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"