Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem
Date: Tue, 20 Sep 2011 11:08:22
Message-Id: 20110920110744.GB6252@localhost
In Reply to: Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem by Ciaran McCreesh
On Tue, Sep 20, 2011 at 11:40:13AM +0100, Ciaran McCreesh wrote:
> On Tue, 20 Sep 2011 03:28:48 -0700 > Brian Harring <ferringb@×××××.com> 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 feasability of a static rescue > > binary (or extremely simplified upgrade pathway). > > boost's just for Python bindings, which are optional. The eselect > dependency is hard, and can't easily be made optional, so ideally > eselect should stick with older EAPIs.
Bit more than just that, going by a quick look. libpcre is 3/4; looks like an old version is intentionally held back. pkgconfig is the same- 0.25-r2 is EAPI2, everything else is EAPI4. You didn't answer the static question btw... ~brian

Replies

Subject Author
Re: [gentoo-dev] Re: RFC: Making backwards-incompatible tree changes | a solution for GLEP 55's problem Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>