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/
