This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Local file tracking class for setup.exe




> -----Original Message-----
> From: Michael A Chase [mailto:mchase@ix.netcom.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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]