On Fri, Jul 1, 2011 at 5:39 PM, Duncan <1i5t5.dun...@cox.net> wrote: > One thing to keep in mind when we're talking about the download of > historical binaries is the obligations of the GPL, etc, in that regard. >... > But once you start shipping historical binaries, as we're talking here,
Actually, I wasn't thinking about providing historical binaries - just ones matching those in a stage3. Binary distribution of stage3 is a problem we already have license-wise. The problem with just unzipping a stage3 on your system is that you break all the package management tracking of files. The solution I'm proposing is to just use a binary emerge to do the exact same thing (perhaps selectively) so that everything is package managed. Now, this will still break anything that has an RDEPEND on a system package with a non-standard use flag. I suspect those kinds of issues are going to be relatively rare. Also, they're easily fixed. The real big problem with an emerge -uD world on a system that is a year old is that the toolchain and other key system packages may not be able to update themselves all in one shot. Maybe the new portage doesn't run on the old python, or you have some kind of circular situation where two toolchain packages don't build with the other's old version. Using a binary repository would let you get a USE-neutral clean copy of any of that stuff installed. There are still things that could go wrong (mostly related to fetching/extraction/python/portage), but the number of components that need to be working for a binary install is much lower than for a full build. So, I would think that it is pretty likely that you could jump straight to a modern system if you did a binary emerge. Then you could do a revdep-rebuild, or even an emerge -e system/world to really clean things up. Maybe there is some obvious flaw in my logic here... Rich
