On Sat, Sep 17, 2011 at 10:59:08PM -0500, Donnie Berkholz wrote:
> 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.
Drawing it back to what spawned it; usex. This isn't git.eclass, this
isn't svn.eclass, nor is it any of the other complex eclass
functionality. It's a core function that benefits the rest and
should be in EAPI.
That function is pretty clearly destined for EAPI, hence this long
thread where you're bitching "avoid EAPI, do eclass only" and I'm
bitching back "that's stupid for xyz reasons, do a compat eclass and
push it into the next EAPI".
> 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.
Stacking on gentoo-x86 means you get *everything* for that repository.
If all you want is a random function out of eutils, that's a *lot* of
uncontrolled change to have intermixed with your overlays eclasses
(even worse, if the eclasses truly overlay into gentoo-x86, that
introduces compatibility issues there too).
It's a matter of change control; using the unpack example again, if
I'm maintaining a 6 month old snapshot for production deployment,
which is preferable for getting an updated unpack function:
1) unpack is in eclasses; do I sync gentoo-x86 eclasses into my
snapshot? Do I just cherry pick the updated function out, into my own
2) if it's part of a new EAPI, do I cherry-pick the update for my $PM,
and then use that EAPI in my ebuilds that needs that new
#1 is exactly the sort of scenario where you'll start getting
copy/pasting; you can state "well they should just update", but that's
completely unrealistic. Every production deployment of gentoo (or
derived from) that I've seen has snapshot'd periodically for
> > 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.
They should, but api compatibility of an eclass *can* be fluid- in the
past it was a locked API purely because of portage environment saving
issues. That's been resolved, there isn't any strict requirement that
the eclass maintain API compat now. You're trying to rely on people
doing best practices- for format building blocks
(use_with/usex/unpack/etc), that's not sane.
> > 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?
If funtoo wants their own unpack, awesome. Shove it into an eclass
under a different name. If they want to modify unpack /directly/,
they better damn well change the EAPI the ebuild uses.
prefix, kde, hell even a crazy python attempt have all had custom
EAPI's built out for exactly scenarios like this.
The point of EAPI is that it's an agreed to format. Embrace/extending
it hasn't intentionally occured yet since the versioning is
*designed* to allow for people to cut their own formats as needs be
> > 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.
Think that through; you're suggesting "shove it all in gentoo-x86";
that increases the lockstep requirements.
I suspect an easier way to wrap this thread up is if you just state
what you want for backwards compatibility- in a seperate thread you
already proposed basically locking out systems older than 6 months,
and this discussion (moreso the "eapi slows our development" subtext)
is along the same lines.
Layout what you think it should be, how you think EAPI should be
managed (what goes in, what doesn't, etc), how derivatives should be
handled, how we'll deal w/ installations/derivative distros that grab
snapshots of the tree and run from that (chromeos is a public
example, I've seen multiple private deployments using the same
approach), and what /you/ think it should be rather than sniping at
the examples I've been giving why things are the way they are.
As is, this thread isn't really going anywhere- better to just skip
ahead to what you think it should be rather than random arguments
about what it is now.