Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Mon, 19 Sep 2011 22:53:15 +0000 (UTC)
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:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Alex Alexander
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Rich Freeman
References:
RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Alex Alexander
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by thread:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Previous by date:
Re: udev and /usr
Next by date:
Re: udev and /usr


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.