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

[Alex Alexander]

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?
-- 
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com