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: Pacho Ramos <pacho@g.o>
Subject: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 15:09:01 +0200
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?
Attachment:
signature.asc (This is a digitally signed message part)
Replies:
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Patrick Lauer
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Duncan
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
-- Michał Górny
References:
RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
-- Alex Alexander
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by thread:
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Previous by date:
Re: Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Next by date:
Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem


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.