From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1840 invoked by alias); 2 Mar 2002 01:05:46 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 1782 invoked from network); 2 Mar 2002 01:05:45 -0000 Received: from unknown (HELO itdomain003.itdomain.net.au) (203.63.157.208) by sources.redhat.com with SMTP; 2 Mar 2002 01:05:45 -0000 Received: from lifelesswks ([144.137.124.33]) by itdomain003.itdomain.net.au with Microsoft SMTPSVC(5.0.2195.3779); Sat, 2 Mar 2002 12:05:43 +1100 Message-ID: <003a01c1c186$8ad66790$0200a8c0@lifelesswks> From: "Robert Collins" To: , "Randall R Schulz" References: <20020301101318.16349.qmail@oak.oeko.net> <20020301101318.16349.qmail@oak.oeko.net> <5.1.0.14.2.20020301073006.024b18c8@pop3.cris.com> <5.1.0.14.2.20020301075448.00aaf730@pop3.cris.com> <5.1.0.14.2.20020301160226.02538020@pop3.cris.com> <5.1.0.14.2.20020301164449.029d6750@pop3.cris.com> Subject: Re: "local install"? Date: Fri, 01 Mar 2002 17:05:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 02 Mar 2002 01:05:43.0830 (UTC) FILETIME=[60E23360:01C1C186] X-SW-Source: 2002-03/txt/msg00056.txt.bz2 ----- Original Message ----- From: "Randall R Schulz" > >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. > 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'. Rob -- 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/