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
Date: Wed, 19 Dec 2001 16:14:15 EST
To: cygwin-developers <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: Is this the new format for the download directory
X-Mailer: Virtual Access by Atlantic Coast PLC, http://www.atlantic-coast.com/va
Message-Id: <VA.00000a0b.00147003@thesoftwaresource.com>
From: Brian Keener <bkeener AT thesoftwaresource DOT com>
Reply-To: bkeener AT thesoftwaresource DOT com
In-Reply-To: <02a401c18861$5f5ab570$0200a8c0@lifelesswks>
References: <VA DOT 00000a03 DOT 00abc27d AT thesoftwaresource DOT com> <02a401c18861$5f5ab570$0200a8c0 AT lifelesswks>

Robert Collins wrote:
> Sortof. We can put all the files in one flat directory per site, but
> that's kinda ugly.
> 
> This is still in flux. Please feel free to suggest better approaches.
>
I'll have to give this some thought.  Not sure what you mean by one flat 
directory but if it means all package dropped in one folder then your right 
that is ugly.  If it means each set of packages in their own folder possibly 
without the contrib and latest level then I heartily disagree - I find that 
structure quite easy to work with.  The current method is cumbersome, terribly 
confusing, difficult to find what all versions I currently have on my disk that 
I might no longer need and on top of that I'm not sure I care what mirror it 
came from - I'm sure there is a good reason and that those more experienced and 
in the know can appreciate it, but for me - it is way more than I need.  

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.  

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.

Those are my thoughts for now and please accept this as only discussion - not 
criticism.  Ii will have to think more on this before I venture an alternate 
approach.

bk