Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <008a01c1013a$470a8fd0$6464648a@ca.boeing.com>
From: "Michael A. Chase" <mchase AT ix DOT netcom DOT com>
To: <cygwin-developers AT sources DOT redhat DOT com>
References: <00b701c1010a$39ddea30$6464648a AT ca DOT boeing DOT com> <20010629223139 DOT B11334 AT redhat DOT com>
Subject: Re: Local Setup Cache
Date: Sat, 30 Jun 2001 00:50:36 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin-developers AT sources DOT redhat DOT com>
Sent: Friday, June 29, 2001 19:31
Subject: Re: Local Setup Cache


> On Fri, Jun 29, 2001 at 07:12:49PM -0700, Michael A. Chase wrote:
> >I wrote a script to remove archives from my local cache that aren't
listed
> >in setup.ini.  I suspect that this is a growing problem especially with
the
> >code that adds unmentioned files to the module list in choose.cc.  Would
it
> >be reasonable to put something in setup.exe to remove obsolete archives?
>
> Hmm. The logic that I added to do this really needs for the FIXME comment
> that I added to be done before we release this.  Currently, it will
randomly
> insert packages in inappropriate "trust" positions.
>
> I hadn't considered the scenario of latest/bash getting filled up with
older
> versions of bash.  The current code could easily put an older version of
bash
> in the "experimental" postion rather than the "prev" condition.

Many packages have "prev" a version already but no "test" version, so the
most likely situation is that a version that has been replaced will get
slotted in the "test" position.  Hence my question of whether putting code
in setup.exe to weed out obsolete versions would be reasonable.  I am
willing to do the coding after the current burst settles down a bit.

An easier alternative to code would be to ignore versions that aren't in
setup.ini whose version numbers are lower than the current, previous, or
test version.  That still leaves people (especially the less experienced or
attentive) with obsolete versions in their local cache.  Eventually the old
versions will fill up their disk.  Is this part of the plan for taking over
the universe?  I don't know how this can be used to control the fan on
laptops though.  :}b

--
Mac :})
** I normally forward private questions to the appropriate mail list. **
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.