Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com Date: Mon, 22 Apr 2002 14:24:03 -0700 (Pacific Daylight Time) From: Michael A Chase Subject: Re: Bug in setup.exe 2.194.2.24 To: Robert Collins , Cliff Hones , Cygwin-Apps MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Disposition: INLINE References: In-Reply-To: Reply-To: Michael A Chase Message-Id: On Mon, 22 Apr 2002 10:36:09 +1000 Robert Collins wrote: > > From: Michael A Chase [mailto:mchase AT ix DOT netcom DOT com] > > Sent: Monday, April 22, 2002 10:05 AM > > > This means that changing mirrors will cause repeated > > > downloads, and that selecting all the mirrors you want to > > use is the > > > most efficient approach. It looks like Cliff's problem isn't with a variety of mirrors being used, but that choose.cc is ignoring the presence of the already downloaded files from currently selected mirrors when the associated package/version hasn't been installed in the Cygwin installation. When not installing, packagedb shouldn't be populated from /etc/setup/installed.db. It should be populated from the list of available files. That also means packagedb::flush() should be a noop if not installing. > > Perhaps a separate class should be defined for tracking files > > found and their possible package associations. This could be > > used later for removing obsolete versions of package archive files. > > Hmmm. Could you enlarge on this idea? One of long term goals is to only > download setup.ini if it's changed. This in turn allows us to leverage > more mirror sites more quickly, so there should be no reason to change > mirrors once one is happy with the selection. (Compare with apt-get). > > So I'm not too concerned about what files are in non-selected mirror > dirs. Deleting obsolete files from the known mirror dirs... that is of > some interest. However my feeling is that the simplest approach is > > rm (all files - known files). If the files found are tracked independently, then the appropriate file would always be locatable regardless of mirror source and the current multiple find() calls would no longer be required. I'm sending the proposed class description in another email so you can nibble on it separately. -- Mac :}) ** I normally forward private questions to the appropriate mail list. ** Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.htm Give a hobbit a fish and he eats fish for a day. Give a hobbit a ring and he eats fish for an age.