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: Alex Alexander <wired@g.o>
Subject: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 01:14:38 +0300
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
Attachment:
signature.asc (Digital signature)
Replies:
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Zac Medico
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Pacho Ramos
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Duncan
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
finding reverse dependencies for arch testing (and other purposes)
Next by thread:
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: Please don't use IUSE=static-libs unless really necessary


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.