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
1 On 09/20/11 17:19, Zac Medico wrote:
2 > On 09/19/2011 03:14 PM, Alex Alexander wrote:
3 >> My idea is simple. When incompatible changes have to be introduced to the
4 >> tree, push a new version of portage that includes support for all the new
5 >> features we want to provide.
6 >>
7 >> Then, freeze the tree and clone it into a revbumped rsync module, i.e.
8 >>
9 >> SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage-r1"
10 > It's a waste to provide the old copies via rsync. A similar alternative
11 > that would solve that is to have a file in the tree that maps older
12 > EAPIs to snapshots. That way, after a person syncs and finds that the
13 > tree's EAPI is not supported, their package manager can easily locate
14 > and download a tree snapshot (from any gentoo mirror) which is supported
15 > by the current package manager.
16 Good idea, but won't work retroactively out of the box. So you'd need a
17 helper script to figure out your current state (using portage version
18 and tree snapshot maybe), then prepare the environment to upgrade
19 (and how do you handle the "common" case of python 2.5 only which
20 doesn't allow newest portage anyway?)

Replies