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:  Local file tracking class for setup.exe
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Wed, 24 Apr 2002 00:09:26 +1000
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <FC169E059D1A0442A04C40F86D9BA7600C5EDE@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>,
   "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 g3NETHR16419



> -----Original Message-----
> From: Michael A Chase [mailto:mchase AT ix DOT netcom DOT com] 
> Sent: Tuesday, April 23, 2002 7:24 AM

> > 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).
> 
> This class tracks the files in the local cache so other parts 
> of setup.exe can ask it if a file is present or not instead 
> of having to look for themselves.  As files are downloaded 
> they can be added to the list.

Currently the only places that files are asked for - based on setup.ini
- is choose.cc (for local_installs) and download.cc. I see value in
abstracting the checks though. 

> I see this being especially useful in choose.cc or packagedb 
> when only downloading.  

I'm not clear on why packagedb cares about cached files.

>It would also make installing simpler 
> since there would be a single source for tracking which file 
> to use for a given package version.

This is already the case - packagesource->bin->Cached() or
packagesource->src->Cached().
 
Ok, thanks for providing a rough class outline, I understand better what
you are suggesting. If I read it right, what you are proposing is a
singleton collection that represents all the files/packages in the local
download dir, and may or may not be persistent cross-runs.

I don't like this for the following reasons:
1) package->file mapping should be done via the package_source/packagedb
interface, not a local file representation. Populating packagedb
information once the localdir is know is an *existing* interface to
store this data. Making more data persistent for packagedb is the (to
me) logical extension to accomplish persistence.
2) It lets us track all known mirrors.

I do like it for the following reasons:
1) It allows abstraction of file->package mapping for setup.ini-less
installs.
2) It lets us track all known mirrors

So in summary, if Cached() was populated (ie check_for_cached() called
against each version of the package) before choose.cc was entered, then
there would be no need for choose.cc to scan for known files, but we
would only know about versions listed in setup.ini. How does that sound?

Rob

P.s. vendor is used :}. See package_version.h and or cygpackage.cc.