Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: Phorward.Pharsalia.Com: adobkin owned process doing -bs Date: Thu, 3 Apr 2003 19:45:06 -0500 (EST) From: Alan Dobkin X-X-Sender: adobkin AT Phorward DOT Pharsalia DOT Com To: Robert Collins cc: Cygwin Mailing List Subject: Re: setup.exe final pre-release.. In-Reply-To: <1049407619.20783.10.camel@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 4 Apr 2003, Robert Collins wrote: > On Fri, 2003-04-04 at 07:48, Alan Dobkin wrote: > > > > > My question is this: Why is it necessary to scan every package > > > > in the mirror every time setup is run against a local mirror? > > > > Most of the time, I am only installing a single package or a > > > > few updates. It seems that setup should only check the packages > > > > being installed, and the rest of them should be ignored. > > > > > > How do you create / maintain that local mirror. Via setup, > > > or via an external script of some sort? > > > > Using wget, as recommended from the Cygwin web site. I've been > > doing this the same way for at least a year, and it has worked > > fine for all previous setup releases. > > And it works for this one too. I didn't mean to imply that it doesn't work now, only that the method I've used to create the mirror doesn't seem to be the problem. > It's also clearly noted that cygwins local package directory is > subject to change without notice - I understand that the directory is subject to change, but the nature of a mirror implies that the changes are automatically propogated and thus setup should still work. Are you saying that setup would no longer support the same directory structure that is present on the current mirror sites at that same time? Or in other words, that setup would use different directory structures for local and remote mirrors? This doesn't make sense to me.... > you should use apache or IIS to serve out the mirror and add > it to your mirror selection creen in the custom URL field. > > Then, setup won't check the md5's of every package. This seems like an overly complex workaround just to preserve the existing functionality. And, it has the side effect of creating another cache on each client system and re-downloading each package before it is installed. This negates one of the main reasons why I set up the local mirror in the first place, i.e. so I could maintain a single repository on a local server and avoid having a bunch of local caches on each installation. > The reason setup checks all the md5's is to ensure that what > it's discovered in the cache hasn't been corrupted. That makes sense, but then there should be a way to bypass this check so it doesn't happen every time. Perhaps something like a dirty/clean flag that filesystems use to prevent having to do a fsck/chkdsk every time it's mounted. Setup could set this flag in its cache to dirty every time it does a download and then set it to clean every time the full MD5 scan is done. Or, a more simple workaround would be a setup option to just bypass the initial scan. Doesn't setup check the MD5 sums when it installs the selected packages anyway? Couldn't the scan to check for cache corruption be performed after the package selection screen, so it only affects the packages being installed? At least this would cut down on the long initial delay and combine it with the same time-consuming portion where the packages are being installed. That way the user only has to go get a cup of coffee once during the installation process instead of twice. :-) > There was another thread on this in cygwin-apps. Max > considers it a release blocker, I don't. Accordingly, > I said I was happy to consider patches.... I finally found this thread after a while of searching: http://sources.redhat.com/ml/cygwin-apps/2003-03/threads.html#00443 I don't necessarily consider it a release blocker, but I think other users in the same boat will find it very annoying if there is no bypass option after this version is released. I agree with Max's comment that it will be the #1 complaint. I would gladly write a patch if I had the ability to do it in a reasonable amount of time, but I'm sure others are set up to do it in a small fraction of the time it would take me. Thanks, Alan -- 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/