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