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
From: "Robert Collins" <robert DOT collins AT syncretize DOT net>
To: <cygwin-apps AT cygwin DOT com>
Subject: Setup Cache dir maintenance.
Date: Tue, 11 Jun 2002 23:00:16 +1000
Message-ID: <00a201c21147$ef1bc540$0200a8c0@lifelesswks>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal

I've finally got my thoughts on this one straight... How does this
sound:

0) We change the setup.ini writing to the cached dirs to be a dump from
the package database of entries for that mirror.

1) After each setup.ini download, before committing to disk, setup
reviews the on-disk setup.ini for each mirror site, and - dynamically -
adds a setup.ini version: entry for each old version where that version
is
A) currently cached.
B) Not in the downloaded setup.ini.

2) Setup (or a console tool with the common code now available) has a
purge mode with a few knobs.
A) keep last n revisions of all packages
B) keep only "current" or only "prev" or only "test". (combinable - i.e.
keep all current/test revisions).

This has several impacts over and beyond purging of files.

1) It automagically adds all cached files to the setup.ini, easing file
version guessing requirements for local installs.
2) It automagically keeps cached files available in the chooser until
purged.

Thoughts? IMO it's a fairly clean design - there's no guesswork as to
versions (current cache wastage aside, that can be addressed with
Michael's tool), it's easy to implement (just emit the appropriate
fields while outputting the setup.ini. Getting the available files is
already implemented and just needs to be called before writing
setup.ini.).

Rob