[gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review

[Duncan]

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@g.o>
> 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.

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.


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.

Would that force the ordering of something else that's a solved problem 
now, to undefined, or is it actually workable, or...?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman