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

2011-09-21 Thread Pacho Ramos
El mié, 21-09-2011 a las 04:00 +, Duncan escribió: > Patrick Lauer posted on Tue, 20 Sep 2011 19:00:38 +0200 as excerpted: > > > On 09/20/11 15:09, Pacho Ramos wrote: > > > > What do you guys think? > >> I haven't ever tried it but, what would occur if that people with > >> really updated sys

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

2011-09-20 Thread Duncan
Patrick Lauer posted on Tue, 20 Sep 2011 19:00:38 +0200 as excerpted: > On 09/20/11 15:09, Pacho Ramos wrote: > > > 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, lat

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

2011-09-20 Thread Pacho Ramos
El mar, 20-09-2011 a las 13:57 +, Duncan escribió: > Pacho Ramos posted on Tue, 20 Sep 2011 15:09:01 +0200 as excerpted: > > > 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

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

2011-09-20 Thread Duncan
Pacho Ramos posted on Tue, 20 Sep 2011 15:09:01 +0200 as excerpted: > 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? I believe it was Mike that pointed me at the error in th

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

2011-09-20 Thread Ulrich Mueller
> On Tue, 20 Sep 2011, Ciaran McCreesh wrote: >> Paludis wise, it's eapi2 indirictely due to boost and eselect. > The eselect dependency is hard, and can't easily be made optional, > so ideally eselect should stick with older EAPIs. Eselect's maintainer is well aware of this. I intend to kee

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

2011-09-20 Thread Ciaran McCreesh
On Tue, 20 Sep 2011 04:07:44 -0700 Brian Harring wrote: > You didn't answer the static question btw... Because the answer's complicated! The short version is, it could be made to work, if there's a need for it, and so long as you've got gcc 4.5 for static libstdc++ support, but it won't work rig

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

2011-09-20 Thread Brian Harring
On Tue, Sep 20, 2011 at 11:40:13AM +0100, Ciaran McCreesh wrote: > On Tue, 20 Sep 2011 03:28:48 -0700 > Brian Harring wrote: > > Paludis wise, it's eapi2 indirictely due to boost and eselect. > > Looking at the eapi depgraph for that, doesn't look particularly > > viable for upgrading from a EA

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

2011-09-20 Thread Dirkjan Ochtman
On Tue, Sep 20, 2011 at 12:28, Brian Harring wrote: > Intent is to restore it to EAPI0- frankly it really depends on what > the python teams intentions are for EAPI0, currently that support is > marked to be removed on "06/2011". We'd have to take a look at the complexity distribution, but I thin

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

2011-09-20 Thread Ciaran McCreesh
On Tue, 20 Sep 2011 03:28:48 -0700 Brian Harring wrote: > Paludis wise, it's eapi2 indirictely due to boost and eselect. > Looking at the eapi depgraph for that, doesn't look particularly > viable for upgrading from a EAPI<2 manager for paludis. I'll leave > it to Ciaran to comment on the fea

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

2011-09-20 Thread Patrick Lauer
On 09/20/11 09:12, Alex Alexander wrote: >> The only real gotcha is if portage is so old that it can't handle the >> binary packages. However, to get around that we really just need a >> set of step-wise binary updates for portage itself so that you can >> sequence it up to something that can inst

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

2011-09-20 Thread Brian Harring
On Mon, Sep 19, 2011 at 08:46:10PM -0400, Rich Freeman wrote: > On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > At least an initial read suggests that you just multiplied the mirror > > space requirements by however many times you use this trick. ?I don't > > believe infra

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

2011-09-20 Thread Alex Alexander
On Mon, Sep 19, 2011 at 08:46:10PM -0400, Rich Freeman wrote: > On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.dun...@cox.net> wrote: > > At least an initial read suggests that you just multiplied the mirror > > space requirements by however many times you use this trick.  I don't > > believe infra

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

2011-09-19 Thread Alex Alexander
On Mon, Sep 19, 2011 at 10:53:15PM +, Duncan wrote: > Alex Alexander posted on Tue, 20 Sep 2011 01:14:38 +0300 as excerpted: > > > 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 incomp

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

2011-09-19 Thread Duncan
Rich Freeman posted on Mon, 19 Sep 2011 20:46:10 -0400 as excerpted: > For most changes, honestly, I think the cleanest option is to use binary > packages. If you build a generic set of @system binary packages then > you can emerge -K them and get a bootstrappable system no matter how > out-of-da

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

2011-09-19 Thread Rich Freeman
On Mon, Sep 19, 2011 at 6:53 PM, Duncan <1i5t5.dun...@cox.net> wrote: > At least an initial read suggests that you just multiplied the mirror > space requirements by however many times you use this trick.  I don't > believe infra's going to go for that. > Yup - and everybody needs to mirror all th

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

2011-09-19 Thread Duncan
Alex Alexander posted on Tue, 20 Sep 2011 01:14:38 +0300 as excerpted: > 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