On Mon, 19 Oct 2015 15:49:06 -0400 Rich Freeman <ri...@gentoo.org> wrote:
> On Mon, Oct 19, 2015 at 2:28 PM, Alexis Ballier <aball...@gentoo.org> > wrote: > > > > However, as you say, putting it in cmake-utils needs to be properly > > thought so that it doesn't conflict with other eclasses: Hence the > > need to properly define what eclasses should call eapply_user and > > apply patches and what should not. > > > > That is my main concern. Maybe a package uses cmake and ant. Patches > could affect either. With an automagic design you might have to run > half of each src_configure, then apply patches, then run the other > half of each src_configure. This is my concern too and where I am fearing crappy code :) > > Your initial argument was very convincing, but under those > > conditions, it seems way much saner to make eapply_user idempotent > > and be done. (and maybe in addition require informally that > > eapply_user is called after applying patches, but that'd fall under > > good practices rather than rules) > > The only danger here is that later phase functions to run would be > operating on already-patched sources, when they expect to be running > on unpatched sources. I imagine that usually wouldn't be a problem, > but it of course could be one. > > I do get your analogy to eapply_user not being in the default phase > function. > > This all falls into that general category of correctness vs > convenience. It is more convenient if you can just call eapply_user > at a suboptimal point and not have to mess with your ebuilds. The > same argument could be made for running all the inherited eclass phase > functions and not just one of them. The issue is that this can break > in lots of hard-to-predict ways. I'd rather see things refactored to > deal with this in a more sane manner. It's not about correctness vs convenience: eapply_user idempotent doesn't prevent from doing it correctly. It makes it possible to do it incorrectly though, just like any turing-complete language actually, but it is not clear at all what would be the ratio of "incorrect convenient usage" vs "correct convenient usage": if 99.9% of the tree is fine, then convenience is clearly worth it instead of changing everything to accommodate the remaining 0.1%. eapply_user dying on second call, defined in PMS, OTOH, prevents such flexibility and thus raises a lot of design questions that, as seen here, don't seem to have a clear answer yet and for which it could indeed be worth refactoring. I can't find an example of where the guideline "apply ebuild patches before eapply_user" would not be sufficient: After all, all subsequent phases will also run on user-patched sources and there are millions of ways to make a patch break a package. > That actually makes me wonder if the better solution is to add another > phase - such as src_postprepare or something like that, where you'd > run autotools or whatever. If that were done then you could also make > hasufell happy by just having the PM do the patching after > src_prepare. Maybe that can go in EAPI7. :) src_patch ? :)
