RE: Setup Cache dir maintenance.

["Robert Collins" <robert dot collins at syncretize dot net>]

> -----Original Message-----
> From: cygwin-apps-owner@cygwin.com 
> [mailto:cygwin-apps-owner@cygwin.com] On Behalf Of Max Bowsher
> Sent: Wednesday, 12 June 2002 1:10 AM


> >> Re (1), I think it would be nice to write these supplementary
> >> entries to
> >> separate setup.ini file.
> >
> > Why? That breaks any current third party tools to no gain IMO.
> 
> Good Point. Maybe a new version type tag (alongside 
> curr/prev/test) to indicate
> 'no longer on mirror', then?

Why is it needed? 
 

> > I've documented the advantages multiple times on this list.
> 
> I've searched, really I have, but I have not found these. Are 
> these the 2 points
> in the long answer below?

There are many points :]. The two below are key challenges.

I *know* I've sent ~3 or 4 email with the list of reasons to the list. I
just can't find them in the archives. Anyway, if the 'two points' are
addressed, then I can see if any other challenges arise...
 
> How do you purge old stuff?

Do what?


> > 2) Different mirrors with the same filename, different 
> version numbers
> > and different MD5's in the same directory.
> 
> Can this ever happen? (assuming all the mirrors are official 
> cygwin mirrors)

False assumption. That's not a precondition for setup.exe, not since
federated setup.ini support was introduced. (= multiple mirror support).
 
> Now, to deal with that assumption being false, here is 
> something I'd like to
> suggest:
> 
> Create a new setup.ini tag - say distribution, or 
> supercategory. The official
> distribution would have "cygwin: The Official Cygwin 
> distribution". We could
> also have "kde-cygwin: Experimental K Desktop Environment 
> packages for Cygwin".
> This tag fits into setups chooser, replacing the 'All' root 
> entry in the tree,
> clearly separating official cygwin packages from add-ons.
> 
> It also provides a neat way to partition the cache.
> 
> An idea to think about anyway.

Hmm, it's an interesting approach. I'm not sure it's needed though, as
the metadata about each mirror is already present, so any cache
cleansing can occur with smarts, and that's the only use that comes to
mind for partitioning.
 
> Single tree is good or making CD-R installs.

It's no better or worse than an encoded mirror in the tree. All our
filenames are short, things should be fine.

> And as for setup doing a worse job, well, that what snapshots 
> are there to
> avoid.

Yes, but I wasn't referring to code quality, rather design quality.

Rob