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: Brian Harring <ferringb@...>
Subject: Re: new `usex` helper
Date: Fri, 16 Sep 2011 13:43:15 -0700
On Fri, Sep 16, 2011 at 07:30:14AM -0500, Donnie Berkholz wrote:
> On 02:06 Fri 16 Sep     , Brian Harring wrote:
> > Specious argument; the point of controllable stacking was to avoid the 
> > issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds 
> > (which may not support those modified eclasses) via the old 
> > PORTDIR_OVERLAY behaviour.  This is why multiple repositories have 
> > layout.conf master definitions- to explicitly mark that they 
> > require/consume a seperate repo.
> 
> So let me get this straight — instead, you want overlay users to 
> maintain a copy of every eclass they use, which will almost 
> automatically become outdated and stale because it won't track the 
> gentoo-x86 version?

Where did I say that?

layout.conf exists to allow repo's to explicitly state what they need- 
this means we can have individual overlay stacks, instead of having 
gentoo-x86, overlay1, overlay2, overlay3, with that as a single stack 
(including eclass lookup), it can be broken out as individual stacks.  

This limits the eclass affect for a repo to just what is explicitly 
configured.  This is a good thing.  This is controllable in addition.

What I said from the getgo and you're missing is that pushing EAPI 
implementation into the tree and ignoring EAPI, or having this notion 
that every repository must automatically use gentoo-x86 (pushing the 
format into the tree) is /wrong/; aside from meaning that the format 
definition can now *vary*, which is great for wasting dev time and 
screwing up compatibility, it opens up tweaking/customizing that 
functionality- aka, fragmentation/divergence.  If we did the sort of 
thing you're basically pushing for, how long do you think it would be 
till funtoo added support for a new archive format to unpack?  That's 
a *simple*, and *likely* example of how this can diverge.

Further, doing as you propose means we're flat out, shit out of luck 
/ever/ distributing a usable cache for standalone repositories.  If 
they're bound to the changes of another repository, distributing a 
cache in parallel is pointless (and not doable in current form since 
metadata/cache lacks necessary eclass validation data for overlay 
inheritance).

Fact is, gentoo-x86 has a lot of usable eclass in it, but it's not 
required to be used.  Anything trying to *force* that is very short 
sighted and forgetting history.

You want new EAPI functionality that is bash only?  Awesome, eclass 
compatibility, and EAPI; don't just jam it into an eclass and say 
"EAPI is slow/annoying and I don't want to do it".  Do both, everyones 
happy.

~harring, cranky at revisiting the same arguments over and over


Replies:
Re: new `usex` helper
-- Donnie Berkholz
References:
new `usex` helper
-- Mike Frysinger
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Donnie Berkholz
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: new `usex` helper
Next by thread:
Re: new `usex` helper
Previous by date:
Re: x32 fun pants
Next by date:
Re: Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting


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.