On Wed, 21 Oct 2015 01:24:00 +0000 (UTC) Duncan <[email protected]> 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 <[email protected]> > > 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.
