[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review
From:       Alexis Ballier <aballier () gentoo ! org>
Date:       2015-10-21 7:29:17
Message-ID: 20151021092917.366d3a37 () gentoo ! org
[Download RAW message or body]

On Wed, 21 Oct 2015 01:24:00 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Alexis Ballier posted on Tue, 20 Oct 2015 12:25:07 +0200 as excerpted:
> 
> > On Tue, 20 Oct 2015 06:00:15 -0400 Rich Freeman <rich0@gentoo.org>
> > wrote:
> >   
> >> So, perhaps it is a fair question to ask what is the specific harm
> >> from allowing it to be a no-op on subsequent calls, other than
> >> encouraging a coding practice that could possibly have other
> >> unrelated effects?  
> > 
> > Yep; I can't see any real harm, but this is probably based on a
> > limited view of the big picture.
> > However, I do think the practice should be discouraged, but 'let
> > be' in specific cases like for eclasses co-existence. Actually,
> > just like any other (non breaking) QA issue is handled I think.  
> 
> Wouldn't the ultimate effect of "let be", assuming the simplest first-
> eclass-applies rule, effectively undo the entire purpose of having a 
> mandatory eapply_user in the first place?
> 
> IOW, now, without some hook, users can't depend on epatch_user.
> 
> Wouldn't "let be" simply define eapply_user as just as undependable,
> if not more so, because users couldn't simply pickup patches, dump
> them in ${PM_LOCAL_PATCHDIR}, and expect them to actually apply
> properly, because the first eapply_user would apply them and then the
> patches other eclasses attempt to apply would break, triggering a die.

'let be' means that ebuild patches are applied before; whatever you may
invent, PM has no way to prevent:

src_prepare() {
	some_eclass_that_calls_eapply_user_exactly_once
	epatch "something"
}

what you describe is not fixed by dying on second eapply_user call, and
'let be' actually means we have to face it, understand it and handle it
properly


> And if eapply_user is as undependable, why go thru the whole empty 
> exercise in the first place?  Just leave epatch_user alone, because
> after all, users who really want it to be dependable can already
> hook-apply it as necessary.


'must be called at least once' makes it quite dependable I think


> Thus, this really does need worked thru, either somehow forcing the 
> eapply_user to be applied once, after everything else, ignoring
> earlier calls (the new src_prepare2 phase, with the PM running
> eapply_user between the two and 2 only doing whatever auto* magic,
> etc, needs done), or forcing "exactly once" wording, effectively
> forcing eclasses to behave and not call it, which in turn forces the
> ebuild to call both the individual eclass functions and eapply_user,
> at the appropriate time.
> 
> But thinking about it a bit, what happens if eapply_user is defined
> as a PM function/phase that will be called exactly once... between
> src_prepare and src_configure?
> 
> Then existing patch functionality can continue to be called by the 
> eclasses as it is now, perhaps a bit of a mess, but no change so it's
> a mess we've generally already adjusted to, eapply_user gets called
> as a PM function, and all the auto* and etc magic gets called in
> src_configure, just before the normal configure functionality.

that's another solution, but src_configure was meant for, heh,
configure, and src_prepare was meant for preparing the sources;
calling autotools in something else than src_prepare triggers warnings
I think. Nothing prevents from adding new phases, but as already said,
it's a bit late for eapi6 :/

[...]

Alexis.

[prev in list] [next in list] [prev in thread] [next in thread]