Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
From: "Robert Collins" <robert DOT collins AT syncretize DOT net>
To: "'Max Bowsher'" <maxb AT ukf DOT net>, <cygwin-apps AT cygwin DOT com>
Subject: RE: Setup Cache dir maintenance.
Date: Tue, 11 Jun 2002 23:53:21 +1000
Message-ID: <00a301c2114f$593ca370$0200a8c0@lifelesswks>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <005d01c2114b$25d1efd0$d2b08c09@wdg.uk.ibm.com>


> -----Original Message-----
> From: cygwin-apps-owner AT cygwin DOT com 
> [mailto:cygwin-apps-owner AT cygwin DOT com] On Behalf Of Max Bowsher
> Sent: Tuesday, 11 June 2002 11:23 PM

> 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)

Yes. Until step 1 is introduced. If we don't do 0) then step 1 needs to
reparse the file to determine where to add the entries.
 
> Re (1), I think it would be nice to write these supplementary 
> entries to
> separate setup.ini file.

Why? That breaks any current third party tools to no gain IMO.
 
> 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.

Impatient answer:
I've documented the advantages multiple times on this list. No one has
yet offered solutions to them for a 'single tree' layout. (By which I
mean a setup.ini + release structure + any other dirs used by any
federated mirrors - in short a real mess). Please address those now 2
release old requirements before suggesting we go to a 'single tree'.
I've stated I'm not a 100% happy with the current layout, but all things
considered it's better than anything else I came up with. I'm quite
positive no one here thinks I'm dumb... yet requests for this feature
keep coming up WITHOUT answers to the problems I addressed in this
fashion. Something is not getting the message across. Is it my lack of a
angry statement that it should not be discussed anymore? The tendancy
for folk to maintain the cache themselves and then curse that they can't
find foo? (BTW: I have not looked in my cache for ~ 1 year because setup
does such a good job, for sources, binaries etc. I'm eating this
dogfood.)

Long answer:
It already does all the above processing postprocessing, but without the
smarts. And we've discussed moving everything around, and I've yet to
see any benefit that doesn't outweight the disadvantages. Perhaps you
could address how you'd handle the following situations *without special
cases* (In addition to address the aforementioned issue that prompted
the current layout in the first place).

1) Two mirrors with the same filename in the same directory, with
different MD5's (one per mirror) and logival package names.
2) Different mirrors with the same filename, different version numbers
and different MD5's in the same directory.

Both 1 & 2 are supported today. We lose nothing with the current
behaviour. We can handle 1 and 2 in a consolidated tree if we make it a
flat structure a la apt-get's cache dir... But that would break filename
parsing for current third party tools. AND probably get everyone's backs
up on the naming conventions even more. "Why does setup INSIST on
renaming the files it downloads, as this prevents the use of mirroring
tools to ..... "

Dumb answer:
It's already in a single tree. Top level: legacy + mirror derived
folders. 2nd level and below: per mirror data. What do you mean? (:]).

Real Short answer: 
Why is this 'single tree' such a bugbear. Can't anyone let it read and
respond to even one of my missives that actually request solutions? Or
provide a -meaningful- reason for why it is useful and why we should
wear the semi-inevitable issues when setup does a worse job that it does
now?

Rob