This is the mail archive of the cygwin@cygwin.com 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: "local install"?


Chuck,

At 16:33 2002-03-01, you wrote:
>[please don't send me personal email related to cygwin.  Keep it on the list]
>
>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


>>Yes. We've been over this before. Setup.exe is still the best tool for me 
>>to use to maintain my local Cygwin mirror, and I like wget, too. I don't 
>>really see why you're so adamant about this. Why don't you remove the 
>>"Download from Internet" option if you're so certain setup.exe shouldn't 
>>be used to mirror Cygwin installable packages?
>
>
>bootstrapping.  You can't use wget until after the initial install ('cause 
>you don't have a working cygwin environment yet, as required by wget.exe).
>
>For personal use, yes -- you can do whatever you like.  But when the 
>on-disk database format for downloaded tarballs changes, to support 
>setup's *primary* goal -- the pseudo-mirroring behavior you like may be 
>adversely affected.  This has happened in the new setup -- tarballs from 
>sites are no longer stored in "<dir>/latest" and "<dir>/contrib", but are 
>stored under "<dir>/http%%%mirror.site%path%/contrib" etc.  If you select 
>multiple mirrors, the tarballs will be downloaded into disjoint contrib or 
>latest directories, depending on where they came from.  This disrupts the 
>mirroring behavior you like, but the disruption is nonfatal -- you can 
>still do what you want, but it won't be pretty.  However, the behavioral 
>changes are necessary to support the multisite capability.
>
>Basically, the reason we've been harping that "setup is not a mirroring 
>tool" is to preserve the freedom to change setup's on-disk database and 
>operational behavior in order to support setup's *primary* goal.  If you 
>want a local copy of the tarballs that looks just like 
>ftp://mirrors.rcn.net/ -- setup may no longer do that for you -- or the 
>way it does it may be different than you expect (e.g. the "extra" 
>'http%%%site%path' directory level)
>
>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.

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.


>>>>It still seems to me that control freaks are going to do as I do: 
>>>>Separate download and install.
>>>
>>>
>>>Sure.  And some people (incl. me) still boot their linux boxen into 
>>>console mode and only run X when required.  But that's still no reason 
>>>not to develop xdm/gdm/kdm graphical logon managers.
>>
>>I don't believe that analogy is particularly apt. I'm not smitten with 
>>GUIs and I still don't believe a good IDE exists. If the bulk of the 
>>(vocal) S/W developers were to be believed, syntax coloring and 
>>auto-completion were the end-all of programming support, but I find them 
>>unhelpful and undesirable. "In the beginning was the command line..." I 
>>guess I'm still at the beginning, in some ways.
>
>
>I guess I misunderstood your complaint.  Sorry.
>
>--Chuck


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/


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