which would be very nice, if this could be implemented, b/c 1st: that patch dir/method is one of the coolest features of Gentoo and 2nd: patches of this bug report could be tested more easily : https://bugzilla.gnome.org/show_bug.cgi?id=667954 (instead of creating a local overlay ebuild ...) :-) Reproducible: Always
Isn't this already supported gentoo-wise via some portage hook ?
(In reply to comment #1) Not until EAPI5.
*** Bug 473212 has been marked as a duplicate of this bug. ***
To solve this at the gnome2.eclass level, we would have to either finally start using autotools-utils.eclass or copy autotools-utils_src_prepare's logic for determining whether to run eautoreconf. Due to the number of users throughout the tree and the overlays, many of which have explicit eautoreconf calls and some of which have explicit epatch_user calls, this is a change which cannot be turned on by default. (Even waiting until EAPI6 to enable it by default is still likely to produce python.eclass-like unwelcome surprises for ebuild writers.) My suggestions: (short term) add epatch_user calls to an individual ebuild if users ask, and that ebuild already requires eautoreconf, and it seems will continue to require eautoreconf for the foreseeable future. (long term) gnome3.eclass!
Maybe we should try to use more autotools-utils.eclass for eapi6, as that would also allow us to rely completely on it for other functionalities like .la pruning, and easier multilib support for ebuilds that could need it...
I am still strongly against adding this at eclass level since it will be very difficult to obtain a code that gets it right always. Also it implies a level of magic for ebuild writers that is imho both disturbing and harmful in the long run given that many already consider the eclass to be bloated while it does only simple things. On using autotools*.eclass, I already had a look at it long ago and the main problem is that those eclasses did not support older eclass while gnome2.eclass still does, and it would have ended up in more complex code to wrap it rather than do things directly. However if someone wanted to give a try at a new eclass based on that from the start and that could strip support for old gnome components like scrollkeeper and gconf, maybe that would be worth it but imho, we shouldn't make gnome2.eclass any more complex than it is currently.
https://bugs.gentoo.org/show_bug.cgi?id=473212#c9 This comes from there, but better continue here ;)
(In reply to Alexandre Rostovtsev from comment #2) > (In reply to comment #1) > Not until EAPI5. has any progress been achieved here since?)) It seems like a very useful feature to me.
Reviewing it again, I would go for implementing it in a similar way of autotools-utils.eclass (that way we don't need to inherit all the remaining features). The problem is that, after reading autotools-utils_src_prepare, how could we handle it if we keep running "eautoreconf" when needed instead of relying in AUTOTOOLS_AUTORECONF? I mean: 1. We apply patches that need eautoreconf 2. Run eautoreconf (for them) 3. Run gnome2_src_prepare -> It would compare checksums to see if the user patches need eautoreconf -> would run it *again* if needed. How could we prevent that second running without using something similar to AUTOTOOLS_AUTORECONF?
I'll say it again, just ftr. This is imho going way too far in headaches and complicated logic just to support a, let's be realistic, handful of users.
Yeah, I also never liked much to allow people to so easily add unofficial patches to random packages :/ -> if they are fixes, they need to be reported. For "enhancements" would be different I guess...
*** Bug 508342 has been marked as a duplicate of this bug. ***
*** Bug 511204 has been marked as a duplicate of this bug. ***
*** Bug 511210 has been marked as a duplicate of this bug. ***
*** Bug 511212 has been marked as a duplicate of this bug. ***
*** Bug 511214 has been marked as a duplicate of this bug. ***
*** Bug 511216 has been marked as a duplicate of this bug. ***
*** Bug 511220 has been marked as a duplicate of this bug. ***
*** Bug 511222 has been marked as a duplicate of this bug. ***
*** Bug 511230 has been marked as a duplicate of this bug. ***
*** Bug 511232 has been marked as a duplicate of this bug. ***
*** Bug 511236 has been marked as a duplicate of this bug. ***
*** Bug 511238 has been marked as a duplicate of this bug. ***
*** Bug 511242 has been marked as a duplicate of this bug. ***
*** Bug 511244 has been marked as a duplicate of this bug. ***
*** Bug 511246 has been marked as a duplicate of this bug. ***
*** Bug 511248 has been marked as a duplicate of this bug. ***
*** Bug 511250 has been marked as a duplicate of this bug. ***
*** Bug 511252 has been marked as a duplicate of this bug. ***
*** Bug 511254 has been marked as a duplicate of this bug. ***
*** Bug 511256 has been marked as a duplicate of this bug. ***
*** Bug 511258 has been marked as a duplicate of this bug. ***
*** Bug 511260 has been marked as a duplicate of this bug. ***
*** Bug 511262 has been marked as a duplicate of this bug. ***
*** Bug 511264 has been marked as a duplicate of this bug. ***
*** Bug 511266 has been marked as a duplicate of this bug. ***
*** Bug 511268 has been marked as a duplicate of this bug. ***
*** Bug 511270 has been marked as a duplicate of this bug. ***
*** Bug 511272 has been marked as a duplicate of this bug. ***
*** Bug 511274 has been marked as a duplicate of this bug. ***
*** Bug 511276 has been marked as a duplicate of this bug. ***
*** Bug 511278 has been marked as a duplicate of this bug. ***
*** Bug 511280 has been marked as a duplicate of this bug. ***
*** Bug 511282 has been marked as a duplicate of this bug. ***
*** Bug 511284 has been marked as a duplicate of this bug. ***
*** Bug 511288 has been marked as a duplicate of this bug. ***
*** Bug 511290 has been marked as a duplicate of this bug. ***
*** Bug 511292 has been marked as a duplicate of this bug. ***
*** Bug 511294 has been marked as a duplicate of this bug. ***
*** Bug 511296 has been marked as a duplicate of this bug. ***
*** Bug 511298 has been marked as a duplicate of this bug. ***
*** Bug 511300 has been marked as a duplicate of this bug. ***
*** Bug 511302 has been marked as a duplicate of this bug. ***
*** Bug 510402 has been marked as a duplicate of this bug. ***
*** Bug 541258 has been marked as a duplicate of this bug. ***
*** Bug 542552 has been marked as a duplicate of this bug. ***
*** Bug 549346 has been marked as a duplicate of this bug. ***
We will simply rely on builtin functionality with eapi6 as soon as eclasses are updated for that eapi
I don't think EAPI 6 will help with eautoreconf need but at least it has a clearer perimeter imho.
*** Bug 571362 has been marked as a duplicate of this bug. ***
