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: 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 
fixing.

> 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.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com
Attachment:
pgpIG3qjXyk87.pgp (PGP signature)
Replies:
Re: new `usex` helper
-- Brian Harring
Re: new `usex` helper
-- Michał Górny
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
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:
[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.