Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 13:16:44
Message-Id: 1316524565.1711.3.camel@belkin4
In Reply to: Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Pacho Ramos
El mar, 20-09-2011 a las 15:09 +0200, Pacho Ramos escribió:
> El mar, 20-09-2011 a las 01:14 +0300, Alex Alexander escribió: > > EAPI in profiles and the -live version suffix are some of the improvements > > many people would like to see in the tree. Unfortunately, the risk of breaking > > systems with old versions of portage has been too high, holding evolution > > back. > > > > I've been thinking about a way to solve this that would be easy to implement, > > without any significant compromises and one thing comes to mind: > > > > Manipulation of the SYNC variable (i.e. rsync module), > > combined with tree snapshots. > > > > 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. > > > > It will then provide instructions on how to update the make.conf/SYNC > > and a Y/N prompt to fix it itself. It could even do it automatically, > > but that's debatable. > > > > By doing this we can be sure that any user using the revbumped SYNC have > > an up-to-date portage (if they cheated, well, that's their problem), allowing > > us to use all the new features provided by the latest version of portage. > > > > For the above to work, we would require at least > > - support for multiple rsync modules pointing to different trees > > [also in mirrors] > > - a way to freeze the current state of the tree for the current rsync module > > and push future updates to a revbumped rsync module. > > - update our portage-snapshot tools to use the latest rsync module. > > - other things I'm probably forgetting right now > > > > I'm not sure how much work would be required to make our current > > infrastructure support this, the infra people could shed some light on > > this. > > > > The idea is to use this system sparingly, only when we need to push big > > changes that can't be supplied through an EAPI. Another example would be a > > change that would break the upgrade path. By freezing the tree at the right > > moment, we can be sure that the users will follow a known upgrade path > > that works. > > > > Please keep in mind that my solution isn't trying to be the best thing > > possible. Instead, I'm aiming for something that would do the job and would be > > implemented in a realistic timeframe. > > > > What do you guys think? > > I haven't ever tried it but, what would occur if that people with really > updated systems simply unpack an updated stage3 tarball in their / and, > later, try to update?
updated -> outdated ;)

Attachments

File name MIME type
signature.asc application/pgp-signature