[gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem

[Duncan <1i5t5.duncan@cox.net>]

Alex Alexander posted on Tue, 20 Sep 2011 01:14:38 +0300 as excerpted:

> At the moment, all systems have a SYNC line similar to this:
> 
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
> 
> My idea is simple. When incompatible changes have to be introduced to
> the tree, push a new version of portage that includes support for all
> the new features we want to provide.
> 
> Then, freeze the tree and clone it into a revbumped rsync module, i.e.
> 
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"
> 
> That way the last update provided by the old tree will be the updated
> portage package, which will be aware of the SYNC change.
> 
> After the user installs that update, every subsequent emerge run will
> print a fat red warning telling the user that the tree has been
> revbumped.

At least an initial read suggests that you just multiplied the mirror 
space requirements by however many times you use this trick.  I don't 
believe infra's going to go for that.

A workaround may be to eventually store the frozen tree snapshot in only 
one location, with a path change for the bump and a transparent redirect 
(does rsync handle redirects?) on the others, so those that haven't 
updated yet don't get broken.  (If rsync doesn't handle redirects, 
they'll simply get an rsync error until they investigate, and point at 
the single location for that final update before switching.)

But that's not going to work well for the initial surge, so some sort of 
transition plan will need to be implemented.  One relatively simplistic 
possibility that would at least limit the mirrors space required to 2X, 
for a limited time, would be to specify no more than one such upgrade "in 
flight" at once on the mirror network, with older ones in the single-
location archive, limiting the "in-flight" time to say two months.  
However, while that limits the space requirements to 2X and only requires 
that for a limited time, that's still a significant requirement that's 
unlikely to go over particularly well, so a rather more complex, or at 
least different, proposal seems necessary.

Please consider this in your proposal, and/or point out where I missed 
it, if indeed I did. =:^\

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman