Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Date: 17 Nov 2001 21:56:05 -0500 Message-ID: <20011118025605.17324.qmail@lizard.curl.com> From: Jonathan Kamens To: cygwin-apps AT cygwin DOT com Subject: Non-intuitive setup.exe behavior -- downloading is affected by what's installed? I keep a full mirror of all the current Cygwin packages locally, even though we don't actually install all of them locally on our machines. In the past, I have done that simply by running setup.exe and telling it to download into my local mirror directory -- it would tell me which old packages have been updated or new packages have been created and need to be downloaded. However, when the new version of setup.exe is downloading into a local directory, it apparently by default skips packages that are not already installed on the local machine. For example, when I ran it tonight, it decided to skip indent, since of course I don't have indent installed locally since I've never installed it before. Similarly, it's telling me that it's skipping the download of "cvs" since I don't have it installed. I understand that in the new setup.exe, some packages aren't installed by default. However, it seems to me that when downloading into a local directory, the deciding factor when determining whether to download a package should be whether it has been downloaded in the past, i.e., whether there is a version fo that package in the directory into which downloading should take place. I'm not sure what the default should be for a newly created package, but I personally would prefer for the default to be to download such packages. Of course, I can work around this problem -- I'll just use wget or mirror to mirror the whole tree from one of the Cygwin mirrors instead of downloading it with setup.exe. But I just wanted to comment that the current behavior of setup.exe doesn't seem fully intuitive. Note, however, that it's obvious that a lot of work has gone into the new interface and functionality, and overall, I like it a lot. Thanks! Jonathan Kamens