Gentoo Archives: gentoo-dev

From: Patrick Lauer <patrick@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 17:04:32
Message-Id: 4E78C776.5070705@gentoo.org
In Reply to: Re: [gentoo-dev] RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Zac Medico
On 09/20/11 17:19, Zac Medico wrote:
> On 09/19/2011 03:14 PM, Alex Alexander wrote: >> 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" > It's a waste to provide the old copies via rsync. A similar alternative > that would solve that is to have a file in the tree that maps older > EAPIs to snapshots. That way, after a person syncs and finds that the > tree's EAPI is not supported, their package manager can easily locate > and download a tree snapshot (from any gentoo mirror) which is supported > by the current package manager.
Good idea, but won't work retroactively out of the box. So you'd need a helper script to figure out your current state (using portage version and tree snapshot maybe), then prepare the environment to upgrade (and how do you handle the "common" case of python 2.5 only which doesn't allow newest portage anyway?)

Replies