List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
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,
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
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.
Council Member / Sr. Developer