Re: "local install"?

[Randall R Schulz <rrschulz@cris.com>]

Rob,

[ Our mails are crossing, so just know that I've read both the post I'm 
replying to directly here and the subsequent amplification. I think we are 
mostly just agreeing, albeit loudly. ]


>It did *what* ? How do you reproduce it?

Grumble. That must be an even-day bug, because when I went to try to 
reproduce it just now, the mis-behavior was gone.

Here's what I remember. About a half-dozen package updates had been 
announced since I last updated, so I decided to use them as a test case for 
the new setup.exe. It (NEW setup.exe) downloaded the bulk of those packages 
(including their source bundles) and then reported an error (a size 
mis-match, if I recall correctly) and offered to download again. I say OK 
and it downloaded ALL of those packages again, this time without error. 
Then, for whatever reason, I decided to run through the download again from 
the top, and NEW setup.exe it listed all those packages as requiring download.

All this was with my old trusty favorite mirror: http://mirrors.rcn.net.

At that point, I went back to the previous setup.exe (2.125.2.10) and 
downloaded (again) and installed the latest package updates.

Sorry to alarm you. Sadly, at this point all I can say is that it could 
have been cockpit error (occasionally I forget to switch the radio buttons 
to one of "Download ..." or "Install from Local Directory") or it could 
have been a glitch in setup.exe itself.

If more details surface, I'll pass them along.


More below...


At 17:06 2002-03-01, Robert Collins wrote:
>----- Original Message -----
>From: "Randall R Schulz" <rrschulz@cris.com>
> > >Randall R Schulz wrote:
> > >
> > >>I tried the NEW setup. Let's say it has some problems still. I'll
>switch
> > >>when the kinks are worked out.
> > >
> > >
> > >Okay, so when you said "how can I..." you meant "I know it's supposed
>to
> > >work, but it doesn't for me."  That's a bug report.  Thanks.
> >
> > Let me clarify. Once the NEW setup.exe violated some of my expectations
> > (like knowing enough not to download the same packages over and over again
> > even though they are right there where it put them the last time) I stopped
> > using it. So my attempt to shift- or CTRL- click in the mirrors list was
> > done with setup.exe vers. 2.125.2.10
>
>It did *what* ? How do you reproduce it? Where they (a) from the same 
>mirror, or where you (b) chopping and changing mirrors with each run? If 
>(b) then that is somewhat-expected, and future enhancements will address 
>this. However, the goal is that you select *all* the mirrors you want to 
>download from and then just use those again and again. If (a) then tell me 
>*exactly* what you do to make it happen, and send the .log and .log.full 
>from a couple of runs please.
>
>
> > >Using a REAL mirroring tool will insulate you from such surprises -- but
> > >if you're willing to deal with the changes in setup's behavior, good 
> for you.
> >
> > This I don't understand. If Setup doesn't locally maintain the files it
> > downloads as a "mirror" of the site from which it downloaded them, then how
> > does wget or any other mirroring tool serve me better? If I mirror using
> > wget or FTP Voyager will I be able to install? I surely don't want 300
> > megabytes of files for their own sake or just to be able to say I have
> > them. I want a local package set that I can use to install. Since a local
> > script execution phase has been added to the installer, manual installation
> > is, it seems, not an option at all. I've never wanted to do so, but the
> > point is that we depend on setup.exe to do installation, so any manner of
> > retrieving the files to install that is not directly usably by setup.exe
> > for the installation per se is not very useful.
>
>You're more than welcome to help create the command line installer. One 
>patch has been submitted, and feedback given, but no futher news has been 
>heard. Likewise I've put qutie some effort towards making the engine of 
>setup be able to run under unix, and when that is combined with command 
>line parameters, there will exist a mirroring tool that understands 
>setup.ini's and can run from a script etc. etc. And yes, setup.exe will do 
>the right thing if you use wget or FTP voyager - always. We won't break that.

That's all very nice, but I'm actually completely contented with what we 
have now. Let me be clear that I have no problems or complaints with setup 
(old or new, with the now retracted exception described above). I'm very 
happy with what you (all) have given us. Considering I started using Cygwin 
with b18, you can understand that I have a fair perspective on the 
improvements, including but not limited to installation support, over the 
past several years. It's just that I have a hard time accepting the 
repeated admonition that setup.exe is "not a mirroring tool" when clearly 
it mirrors Cygwin just fine, for my purposes. I cannot see why one would 
use it for any other purpose, and perhaps that's what you're trying to 
forestall.

I certainly do reach for wget for all my general-purpose mirroring and 
Internet retrieval--I love it!


> > I'm a software developer, too. I fully understand and accept the need to
> > keep one's options open. Ideally this is done by careful wording of specs.
> > I guess that doesn't really apply here, since we're not talking about an
> > API or any other highly formal (or very complex) specification.
> > Nonetheless, I'm more than happy accommodate such hedges and reserved and /
> > or (pre-) announced behavior changes (e.g., removal of the old
> > interpreatation of the "//" file name prefix in the Cygwin DLL). It would
> > be nice to know, of course, what the anticipated change is. Just saying
> > "Here's a feature. It's there in plain sight. Please don't use it." without
> > adding "lest you risk ..." is kind of hard to accept.
>
>I've not said that :}. Chuck didn't say that either. Paraphrasing what he 
>said : 'don't expect setup.exe to behave like a mirroring tool'. And 
>'don't depend on the setup.exe local cache dir structure to remain the same'.

OK, but if the "local cache dir" is not a mirror, as is commonly 
understood, then telling me to use a tool such as wget that will produce a 
conventional "mirror image" is asking me not to be able to install.

Either setup.exe "mirrors" the download site, or a conventional "mirroring" 
tool is unusable as a substitute for the download functionality of 
setup.exe. I don't see how it can be both.


>Rob


Randall Schulz
Mountain View, CA USA


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/