Re: Setup Cache dir maintenance.

["Max Bowsher" <maxb at ukf dot net>]

Robert Collins <robert.collins@syncretize.net> wrote:
>> Sounds interesting... can you explain more about (0)
>> ...
>
> 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.

Oh. Yes. Duh.

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

Good Point. Maybe a new version type tag (alongside curr/prev/test) to indicate
'no longer on mirror', then?

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

Sorry!

> I've documented the advantages multiple times on this list.

I've searched, really I have, but I have not found these. Are these the 2 points
in the long answer below?

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

How do you purge old stuff?

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

Can this ever happen? (assuming all the mirrors are official cygwin mirrors)

Now, to deal with that assumption being false, here is something I'd like to
suggest:

Create a new setup.ini tag - say distribution, or supercategory. The official
distribution would have "cygwin: The Official Cygwin distribution". We could
also have "kde-cygwin: Experimental K Desktop Environment packages for Cygwin".
This tag fits into setups chooser, replacing the 'All' root entry in the tree,
clearly separating official cygwin packages from add-ons.

It also provides a neat way to partition the cache.

An idea to think about anyway.

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

Single tree is good or making CD-R installs.
And as for setup doing a worse job, well, that what snapshots are there to
avoid.

> Rob

Max.