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 trees? 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 functionality? #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 stabilization reasons. > > 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 for experimentation. > > 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. ~harring
