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
Date:	Mon, 22 Apr 2002 14:24:03 -0700 (Pacific Daylight Time)
From:	Michael A Chase <mchase AT ix DOT netcom DOT com>
Subject:	Re: Bug in setup.exe 2.194.2.24
To:	Robert Collins <robert DOT collins AT itdomain DOT com DOT au>,
	Cliff Hones <cliff AT aonix DOT co DOT uk>,
	Cygwin-Apps <cygwin-apps AT sources DOT redhat DOT com>
MIME-Version:	1.0
References:	<FC169E059D1A0442A04C40F86D9BA7600C5EB5 AT itdomain003 DOT itdomain DOT net DOT au>
In-Reply-To:	<FC169E059D1A0442A04C40F86D9BA7600C5EB5@itdomain003.itdomain.net.au>
Reply-To:	Michael A Chase <mchase AT ix DOT netcom DOT com>
Message-Id:	<E16zlIa-0003nI-00@granger.mail.mindspring.net>

On Mon, 22 Apr 2002 10:36:09 +1000 Robert Collins <robert DOT collins AT itdomain DOT com DOT au> wrote:

> > From: Michael A Chase [mailto:mchase AT ix DOT netcom DOT com] 
> > Sent: Monday, April 22, 2002 10:05 AM
> 
> > This means that changing mirrors will cause repeated 
> > > downloads, and that selecting all the mirrors you want to 
> > use is the 
> > > most efficient approach.

It looks like Cliff's problem isn't with a variety of mirrors being used,
but that choose.cc is ignoring the presence of the already
downloaded files from currently selected mirrors when the associated
package/version hasn't been installed in the Cygwin installation.

When not installing, packagedb shouldn't be populated from
/etc/setup/installed.db.  It should be populated from the list of available
files.  That also means packagedb::flush() should be a noop if not installing.

> > Perhaps a separate class should be defined for tracking files 
> > found and their possible package associations.  This could be 
> > used later for removing obsolete versions of package archive files.
> 
> 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). 
> 
> So I'm not too concerned about what files are in non-selected mirror
> dirs. Deleting obsolete files from the known mirror dirs... that is of
> some interest. However my feeling is that the simplest approach is
> 
> rm (all files - known files).

If the files found are tracked independently, then the appropriate file
would always be locatable regardless of mirror source and the current
multiple find() calls would no longer be required.

I'm sending the proposed class description in another email so you can
nibble on it separately.

-- 
Mac :})
** I normally forward private questions to the appropriate mail list. **
Ask Smarter: http://www.tuxedo.org/~esr/faqs/smart-questions.htm
Give a hobbit a fish and he eats fish for a day.
Give a hobbit a ring and he eats fish for an age.

- Raw text -