On 10/17/2015 03:07 PM, Ulrich Mueller wrote: >>>>>> On Sat, 17 Oct 2015, hasufell wrote: > >> And still doesn't give sufficient control to the user. Documenting >> proper hooks is more useful. > > Nothing prevents the PM from implementing eapply_user() as a hook. >
Whether that will be the case is undefined. My points about eapply_user() are: * may not be implemented by a given PM at all * only works for EAPI=6 and not for previous EAPIs * for previous EAPIS epatch_user is not consistently used for the whole tree and cannot be relied upon * the entry point is defined by the ebuild, not by the user, so less control (e.g. there are cases where you would even want to apply patches pre_src_compile) * requires fixing a lot of ebuilds with the chance of introducing "bugs", because eapply_user is called in a weird place * unreliable for overlays (either because they don't call eapply_user, do it wrong, use an older EAPI or do other funky stuff) * configuration format/locations will be dictated by the PM, which may or may not be sufficient for the user Because of that, no one who wants consistent user-patch support will want to rely on epatch_user alone and even less on eapply_user. I think it's a waste of time, but it certainly does not affect me, since I will just keep doing the same thing with hooks or overlays. But if we follow simplicity, it makes sense to just drop this idea, since there already is a solution that works consistently and in the way the user intends.
