Re: [gentoo-dev] new `usex` helper

[Brian Harring <ferringb@gmail.com>]

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