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
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-dev@g.o
From: Donnie Berkholz <dberkholz@g.o>
Subject: Re: new `usex` helper
Date: Fri, 16 Sep 2011 07:30:14 -0500
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?

> What you're basically proposing is a variation of the "push format 
> definitions into a central tree, and require everyone to use that 
> central tree".  This discussion has come and gone; I say that being 
> one of the folks who was *pushing for the repository solution*.  The 
> problem there is it fundamentally enables (more forces) fragmentation.

I think Gentoo will always provide one or a set of "official" central 
repositories, that's pretty much the definition of a distribution. So 
yes, I'm saying that generally useful stuff could go into one of these 
repositories, which (in the multi-repo case) could be like the eclass 
metaphor for repos; others would depend on it implicitly or explicitly.

> Realistically I assume you're taking the stance "EAPI gets in the way, 
> lets do away with it"- if so, well, out with it, and I'll dredge up 
> the old logs/complaints that lead to EAPI.

I see EAPI as a nice thing for standardizing features that are 
implemented in the PM so they work identically across portage, pkgcore, 
and paludis. But I don't think that implementing things in the PM when 
they could go in an eclass is automatically the best choice. It 
dramatically slows down the speed of iteration, prototyping, and bug 

> rephrase please; either you're saying "everyone uses gentoo-x86" which 
> is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk 
> however which means things can get ugly for derivative repository 
> usage), but still ignores the situations where people have overlays w/ 
> developmental eclasses that they need to selectively control where it 
> overrides (which is where the notion of repo stacking comes into 
> play).

I think I explained above, but let me know if that's not the case.


Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
pgpIG3qjXyk87.pgp (PGP signature)
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Michał Górny
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
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:
[RFC] Adding a tiny install-mask directory list to gx86
Next by date:
Re: x32 fun pants

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.