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

[Donnie Berkholz <dberkholz@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6116 bytes --]

On 04:22 Sun 18 Sep     , Brian Harring wrote:
> 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.

OK, so the implication of what you're saying is that everything in 
eutils.eclass, base.eclass, toolchain-funcs.eclass, flag-o-matic.eclass, 
versionator.eclass, multilib.eclass, prefix.eclass, savedconfig.eclass, 
and maybe even linux-info.eclass and autotools{,-utils}.eclass should go 
into EAPI. All that stuff is pretty generally useful features.

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

Yeah, it seems like the ability to do partial stacking would be nice. 
Perhaps to do so, one wouldn't stack by default but would have a way to 
specify cross-repo dependencies (including eclasses) or file-specific 
UUIDs of some sort.

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

Which still pisses me off. It's like a shared library changing its API 
without bumping SONAME. That makes me wonder whether there's some way we 
could "enforce" it, at least on the level of repoman or test suites to 
examine whether the public interface changed, perhaps by generating a 
cache of the interfaces and comparing to them.

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

Actually Zac said that, and I was trying to clarify if that's really 
what he was saying. 9-12 months is more my feeling, as it gets extremely 
difficult to maintain Gentoo systems without guru-level knowledge around 
there. (Spoken as someone who still gets support emails from a couple of 
previous positions.)

While I would like there to be a "proper" way to express repo-level 
dependencies, properly announce deprecation and updates (e.g. to bash 4) 
in advance as a feature integrated with the PM, and so on, I don't think 
we should block our ability to move forward on these things. The 
situation is essentially the same as it's always been, but our old 
solution is no longer considered good enough and we don't have a new one 
in place, so we're just sitting here.

> Layout what you think it should be,

Layout of what, exactly?

> how you think EAPI should be managed (what goes in, what doesn't, 
> etc),

If it can go in an eclass without strange contortions, put it there.

> how derivatives should be handled,

With white gloves. More seriously, people making derivatives should have 
maximal freedom to experiment, and I'm guessing most of them don't want 
to deal with modifying 3 different PMs written at least partially in 3 
different languages. They'd rather instantaneously support things in the 
same language they use for everything else.

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

Being explicit about our level of support is what we need to do, no 
matter what that level is, so external groups can figure out how to deal 
with that timeline. Our current council-mandated standard is a year, as 
Ulm mentioned in another post, but I'm not aware of any of our 
documentation that actually says this.

It would obviously be good to flood our users with communication 
(website, -announce, news items, etc) before anything that broke even 
just the oldest installations.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]