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

[Alex Alexander]

On Mon, Sep 19, 2011 at 10:53:15PM +0000, Duncan wrote:
> 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. =:^\

Yes, space requirements will increase with this solution, but considering that
it will solve an important issue we're having, I'd say it is worth the
tradeoff.

Still, if space is a big issue, it could be worked around by trimming down the
frozen tree to portage and its dependencies. That can't happen in -r1 though,
since portage must be aware of what's happening so it can block any other
updates and potential downgrades resulting from the trimmed tree and overlays
before the SYNC variable is updated.

Even if we opt to keep the whole tree, we could deprecate and dump it after a year.

Usage of this feature should be as rare as possible. Having 5 revisions of the
rsync tree in a year means we're doing something wrong, but one revision per
year should be affordable (infra-wise) and would solve many problems.

-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com