Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
content-class: urn:content-classes:message
Subject: RE:  Re: Bug in setup.exe 2.194.2.24
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Mon, 22 Apr 2002 10:36:09 +1000
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <FC169E059D1A0442A04C40F86D9BA7600C5EB5@itdomain003.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Michael A Chase" <mchase AT ix DOT netcom DOT com>,
   "Cliff Hones" <cliff AT aonix DOT co DOT uk>,
   "Cygwin-Apps" <cygwin-apps AT sources DOT redhat DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g3M0aDr14941

redirected to a more appropriate mailing list.

> -----Original Message-----
> 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.
> 
> I've tried to look into this, but it's slow going because I'm 
> having trouble following the process flow.  

Feel free to ask questions :}. I don't bite.... much.

> It appears that 
> only the base directory tree and prefix directories for the 
> currently selected mirror sites are checked.  

Exactly. 

> That means if a 
> file was downloaded for a mirror that isn't selected in the 
> current run, it won't get noticed in check_for_cached().

Yup.
 
> 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).

Rob