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: Sat, 17 Sep 2011 22:59:08 -0500
On 13:43 Fri 16 Sep     , Brian Harring wrote:
> 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/;

I'm not necessarily requiring that every repository must automatically 
use gentoo-x86 — just the ones that want to use features in an eclass 
distributed with gentoo-x86. It sounds to me like the logical 
consequence of what you're saying is that every useful function that's 
now or could eventually be in an eclass must instead be incorporated 
into EAPI. I guess I just don't see where you're drawing the line.

What I'm suggesting is that we should add useful stuff to eclasses by 
default. If people want to use that stuff, they can stack on the 
gentoo-x86 repo and inherit the eclass. I don't know why EAPI needs to 
come into it at all.

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

People doing that outside gentoo-x86 should do it the same way as ones 
within it, by bumping the eclass to a new unique name. Ideally one 
that's not just a numeric value so it won't conflict with ours, in the 
same way as EAPI naming.

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

So, what I'm getting out of this is that we should make it harder for 
derivative distributions to innovate? Why should I care if they want to 
do stuff with new archive formats?

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

Not much different from other cross-repository dependencies; you have to 
keep everything in lockstep because who knows what other people will do 
with their repos. Maybe people would want to distribute their own copies 
of forked dependent repositories too, I haven't thought much about it.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com
Attachment:
pgpimUUE1r19S.pgp (PGP signature)
Replies:
Re: new `usex` helper
-- Brian Harring
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
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:
Re: Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
Next by date:
glibc-2.13 stabilization


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.