public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Brian Harring <ferringb@gmail.com>
To: Donnie Berkholz <dberkholz@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] new `usex` helper
Date: Fri, 16 Sep 2011 02:06:05 -0700	[thread overview]
Message-ID: <20110916090605.GD16239@localhost> (raw)
In-Reply-To: <20110916030019.GA5000@comet>

On Thu, Sep 15, 2011 at 10:00:19PM -0500, Donnie Berkholz wrote:
> On 17:29 Wed 14 Sep     , Brian Harring wrote:
> > On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote:
> > > On 19:14 Tue 13 Sep     , Brian Harring wrote:
> > > > On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote:
> > > > > On 17:56 Tue 13 Sep     , Mike Frysinger wrote:
> > > > > > useful enough for EAPI ?  or should i just stick it into eutils.eclass 
> > > > > > ?  OR BOTH !?
> > > > > 
> > > > > I prefer to avoid EAPI whenever possible, as it just makes things slower 
> > > > > and more complex.
> > > > 
> > > > Exactly the wrong approach; it winds up with master 
> > > > repositories/overlays cloning the functionality all over the damn 
> > > > place.
> > > 
> > > Why are people cloning anything if it's in eutils.eclass in gentoo-x86?
> > 
> > There are more repositories than just gentoo-x86, and overlay is *not* 
> > the only configuration in use.
> 
> Who else besides you is using any other configuration? Should we really 
> give a crap about the 0.001% population with some weird setup when we're 
> trying to improve things for the 99.999% one?

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.

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.

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.


> > In the old days of the PM only handling a single overlay stack, what 
> > you're suggesting would be less heinous- heinous in detail, but 
> > pragmatic in reality.  These days it's a regressive approach- 
> > requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding 
> > eapi (resulting in people having to duplicate code into each 
> > repository stack).
> 
> I don't know many people who aren't using gentoo-x86 or a repo that 
> pulls in changes directly from it.

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).
~brian




  reply	other threads:[~2011-09-16  9:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-13 21:56 [gentoo-dev] new `usex` helper Mike Frysinger
2011-09-13 22:01 ` Alec Warner
2011-09-13 22:13   ` Mike Frysinger
2011-09-13 23:08     ` Brian Harring
2011-09-14  2:45       ` Mike Frysinger
2011-09-14  3:04         ` Brian Harring
2011-09-14  3:43           ` Mike Frysinger
2011-09-14  3:56             ` Brian Harring
2011-09-14  6:02         ` Ulrich Mueller
2011-09-14 14:53           ` Mike Frysinger
2011-09-14  2:02 ` Donnie Berkholz
2011-09-14  2:14   ` Brian Harring
2011-09-14 19:16     ` Donnie Berkholz
2011-09-15  0:29       ` Brian Harring
2011-09-16  3:00         ` Donnie Berkholz
2011-09-16  9:06           ` Brian Harring [this message]
2011-09-16 12:30             ` Donnie Berkholz
2011-09-16 14:04               ` Michał Górny
2011-09-16 17:27                 ` Alec Warner
2011-09-16 20:43               ` Brian Harring
2011-09-18  3:59                 ` Donnie Berkholz
2011-09-18 11:22                   ` Brian Harring
2011-09-19  3:16                     ` Donnie Berkholz
2011-09-20 21:20                       ` Brian Harring
2011-09-21 13:11                         ` Donnie Berkholz
2011-09-21 16:37                           ` Alec Warner
2011-09-23  0:41                             ` Donnie Berkholz
2011-09-23  1:04                               ` Alec Warner
2011-09-23  1:15                                 ` Donnie Berkholz
2011-09-17 21:37             ` Zac Medico
2011-09-14  2:47   ` Mike Frysinger
2011-09-14  5:34   ` Ciaran McCreesh
2011-09-14 19:23     ` Donnie Berkholz
2011-09-14 15:03 ` Mike Frysinger
2011-09-21 19:25 ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110916090605.GD16239@localhost \
    --to=ferringb@gmail.com \
    --cc=dberkholz@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox