On 10/18/2015 01:43 PM, Rich Freeman wrote: > On Sun, Oct 18, 2015 at 7:37 AM, hasufell <hasuf...@gentoo.org> wrote: >> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote: >>> On Sat, 17 Oct 2015 14:49:36 +0200 >>> hasufell <hasuf...@gentoo.org> wrote: >>>> You can apply the patches post_unpack or post_src_prepare witht hooks. >>>> What's the problem? >>> >>> Running autorecrap. >>> >> >> You can do that with hooks too (which is not very clean tbh). But at >> that point, you probably want to actually fork the ebuild in an overlay >> if you need to mess with phase internals instead of relying on some >> magic that the ebuild writer might or might not have done properly. >> > > This sounds like "if it isn't done perfectly it isn't worth doing." > If you're going to start by assuming that devs will always design > ebuilds incorrectly, then you might as well just fork all of Gentoo > into your overlay. :) > > People already find epatch_user useful, and I think moving it to PMS > will just make it more consistently useful. Sure, there will be > mistakes, but right now epatch_user is optional, and in the future it > could be considered a QA issue. >
If you are messing with the build system in a patch, there is no guarantee that eautoreconf will be enough. It might or might not be true (see net-irc/hexchat for an example). Are we going to run eautoreconf unconditionally then (which is exceptionally bad)? Maybe the ebuild author doesn't even provide a live ebuild and there's no example for doing the right thing wrt random build systems patches. How about other build systems? You simply cannot do this properly. I think we are encouraging bad practice with this feature by making it part of PMS, causing users to file bugs because their random patches don't work with someones ebuilds. If people need to hack on ebuilds, there are already numerous ways to do that, including doing it properly. Why add another one that is still not consistently thought through? EAPI shouldn't be patchwork.
