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)
Re (1), I think it would be nice to write these supplementary entries to separate setup.ini file. 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. Max. Robert Collins <[EMAIL PROTECTED]> wrote: > I've finally got my thoughts on this one straight... How does this > sound: > > 0) We change the setup.ini writing to the cached dirs to be a dump from > the package database of entries for that mirror. > > 1) After each setup.ini download, before committing to disk, setup > reviews the on-disk setup.ini for each mirror site, and - dynamically - > adds a setup.ini version: entry for each old version where that version > is > A) currently cached. > B) Not in the downloaded setup.ini. > > 2) Setup (or a console tool with the common code now available) has a > purge mode with a few knobs. > A) keep last n revisions of all packages > B) keep only "current" or only "prev" or only "test". (combinable - i.e. > keep all current/test revisions). > > This has several impacts over and beyond purging of files. > > 1) It automagically adds all cached files to the setup.ini, easing file > version guessing requirements for local installs. > 2) It automagically keeps cached files available in the chooser until > purged. > > Thoughts? IMO it's a fairly clean design - there's no guesswork as to > versions (current cache wastage aside, that can be addressed with > Michael's tool), it's easy to implement (just emit the appropriate > fields while outputting the setup.ini. Getting the available files is > already implemented and just needs to be called before writing > setup.ini.). > > Rob
