Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Mon, 19 Sep 2011 22:54:19
Message-Id: pan.2011.09.19.22.53.14@cox.net
In Reply to: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Alex Alexander
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

Replies