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

[Pacho Ramos <pacho@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3235 bytes --]

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 ;)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]