On Fri, Jul 1, 2011 at 5:39 PM, Duncan <1i5t5.duncan@...> 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