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 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"


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