Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <065d01c188d6$aee24d90$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <bkeener AT thesoftwaresource DOT com>,
   "cygwin-developers" <cygwin-developers AT sourceware DOT cygnus DOT com>
References: <VA DOT 00000a03 DOT 00abc27d AT thesoftwaresource DOT com> <02a401c18861$5f5ab570$0200a8c0 AT lifelesswks> <VA DOT 00000a0b DOT 00147003 AT thesoftwaresource DOT com>
Subject: Re: Is this the new format for the download directory
Date: Thu, 20 Dec 2001 08:46:56 +1100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-OriginalArrivalTime: 19 Dec 2001 21:47:30.0361 (UTC) FILETIME=[C214DA90:01C188D6]

----- Original Message -----
From: "Brian Keener" <bkeener AT thesoftwaresource DOT com>
> With the current format I could potentially end up with a given
package spread
> across multiple directories with a different version in each
directory - what a
> nightmare.  One of your design goals as you stated is "1) A downloaded
set of
> files can be used for multiple installs" and I don't see how this is
enhanced
> or impeded with one directory structure over another. I'm sure you
were simply
> listing the goals and not saying that this one was necessarily
pertinent to the
> directory problem, but I picked on it simply because of the problems
we had in
> the path with people downloading for a move to another machine and not
taking
> setup.ini - imagine the problem with multiple setup.ini's and all
these
> different directories.

Setup.ini is in the root of the ftp://... directory. So if you copy that
directory, setup.ini is copied.

> I really believe the simpler we keep the directory structure the
better and
> that all versions of a given package should be in the same folder.  If
we need
> other information about where it came from and such possibly that
should be
> kept in some other index or file somewhere within the download path.
Imagine
> that I download a version of a package from one mirror and then
download the
> same version from another mirror as well - I don't want to copies - I
only want
> the last and that should be the only one I care where it came from.

That won't happen unless you change mirrors - and there is no need to
change mirrors with the multiple-mirror code - just list the mirrors you
want to try with Ctrl-click's and setup will smartly grab the most
recent stuff from whatever mirror has it. It won't duplicate.

It sounds to me like you are talking about ways to *manually* avoid
certain issues, that setup *is able to* handle for you.

Rob