| 1 |
Alex Alexander posted on Tue, 20 Sep 2011 01:14:38 +0300 as excerpted: |
| 2 |
|
| 3 |
> At the moment, all systems have a SYNC line similar to this: |
| 4 |
> |
| 5 |
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" |
| 6 |
> |
| 7 |
> My idea is simple. When incompatible changes have to be introduced to |
| 8 |
> the tree, push a new version of portage that includes support for all |
| 9 |
> the new features we want to provide. |
| 10 |
> |
| 11 |
> Then, freeze the tree and clone it into a revbumped rsync module, i.e. |
| 12 |
> |
| 13 |
> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1" |
| 14 |
> |
| 15 |
> That way the last update provided by the old tree will be the updated |
| 16 |
> portage package, which will be aware of the SYNC change. |
| 17 |
> |
| 18 |
> After the user installs that update, every subsequent emerge run will |
| 19 |
> print a fat red warning telling the user that the tree has been |
| 20 |
> revbumped. |
| 21 |
|
| 22 |
At least an initial read suggests that you just multiplied the mirror |
| 23 |
space requirements by however many times you use this trick. I don't |
| 24 |
believe infra's going to go for that. |
| 25 |
|
| 26 |
A workaround may be to eventually store the frozen tree snapshot in only |
| 27 |
one location, with a path change for the bump and a transparent redirect |
| 28 |
(does rsync handle redirects?) on the others, so those that haven't |
| 29 |
updated yet don't get broken. (If rsync doesn't handle redirects, |
| 30 |
they'll simply get an rsync error until they investigate, and point at |
| 31 |
the single location for that final update before switching.) |
| 32 |
|
| 33 |
But that's not going to work well for the initial surge, so some sort of |
| 34 |
transition plan will need to be implemented. One relatively simplistic |
| 35 |
possibility that would at least limit the mirrors space required to 2X, |
| 36 |
for a limited time, would be to specify no more than one such upgrade "in |
| 37 |
flight" at once on the mirror network, with older ones in the single- |
| 38 |
location archive, limiting the "in-flight" time to say two months. |
| 39 |
However, while that limits the space requirements to 2X and only requires |
| 40 |
that for a limited time, that's still a significant requirement that's |
| 41 |
unlikely to go over particularly well, so a rather more complex, or at |
| 42 |
least different, proposal seems necessary. |
| 43 |
|
| 44 |
Please consider this in your proposal, and/or point out where I missed |
| 45 |
it, if indeed I did. =:^\ |
| 46 |
|
| 47 |
-- |
| 48 |
Duncan - List replies preferred. No HTML msgs. |
| 49 |
"Every nonfree program has a lord, a master -- |
| 50 |
and if you use the program, he is your master." Richard Stallman |
Archives