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
Message-ID: <005d01c2114b$25d1efd0$d2b08c09@wdg.uk.ibm.com>
From: "Max Bowsher" <maxb AT ukf DOT net>
To: <cygwin-apps AT cygwin DOT com>
References: <00a201c21147$ef1bc540$0200a8c0 AT lifelesswks>
Subject: Re: Setup Cache dir maintenance.
Date: Tue, 11 Jun 2002 14:23:03 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

Sounds interesting... can you explain more about (0) below - won't it just
rebuild a setup.ini that is totally equivalent to the one it originally got from
that mirror? (since the in-memory package db was populated from the downloaded
file, and then you reverse the process, and write it out)

Re (1), I think it would be nice to write these supplementary entries to
separate setup.ini file.

Also, given that setup would then be heavily postprocessing its package
directory, should downloaded and md5-verified tarballs be moved to a single
tree - I don't see any advantage in breaking it up by mirror.


Max.


Robert Collins <robert DOT collins AT syncretize DOT net> wrote:
> 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