--- gnome-base/gnome-shell/gnome-shell-3.8.3-r1.ebuild +++ gnome-base/gnome-shell/gnome-shell-3.8.3-r1.ebuild @@ -131,4 +131,6 @@ epatch "${FILESDIR}/${PN}-3.8.3-relock-screen.patch" + epatch_user + eautoreconf gnome2_src_prepare Reproducible: Always
*** This bug has been marked as a duplicate of bug 413299 ***
Patching should be done before eautoreconf because it can modify configure.ac/Makefile.am
This doesn't have much sense either, what will we need to do when we stop applying patches needing to run eautoreconf? Keep that call because we are using epatch_user?
(In reply to Pacho Ramos from comment #3) > This doesn't have much sense either, what will we need to do when we stop > applying patches needing to run eautoreconf? We won't stop applying them because pigs will fly before upstream will accept networkmanager as optional :)
What's the problem with running eautoreconf?
(In reply to Hristo Venev from comment #5) > What's the problem with running eautoreconf? The problem is the theoretical case where a future version of gnome-shell will be released which no longer needs our patches that required eautoreconf. We would want to remove eautoreconf from the ebuild in this case to reduce build time for most users. (Eautoreconf is rather expensive on old/slow machines.) But if some group of users has become used to applying patches to configure.ac or Makefile.am which need eautoreconf afterwards, their patches will break, they will complain, and it will be a general pain for us to deal with. However, because of the differences in opinion between us the gnome gentoo people and the upstream gnome-shell developers, it is likely that for the foreseeable future our patches will be not be incorporated upstream and eautoreconf will continue to be required. So the discussion is rather theoretical. (The solution for other packages, ones which will not need eautoreconf forever, is to incorporate or copy autotools-utils_src_prepare's logic. If we do this at the eclass level [and IMHO we really ought to do it at the eclass level], it would probably require releasing a new version of the gnome eclass. See bug #413299 discussion.)
(In reply to Alexandre Rostovtsev from comment #6) > their patches will break Meant to say: their patches will no longer have the expected effect
+ 14 Jun 2013; Pacho Ramos <pacho@gentoo.org> -gnome-shell-3.8.3.ebuild, + gnome-shell-3.8.3-r1.ebuild: + Run epatch_user (#473212 by Hristo Venev), drop old. +
(In reply to Alexandre Rostovtsev from comment #6) > (The solution for other packages, ones which will not need eautoreconf > forever, is to incorporate or copy autotools-utils_src_prepare's logic. If > we do this at the eclass level [and IMHO we really ought to do it at the > eclass level], it would probably require releasing a new version of the > gnome eclass. See bug #413299 discussion.) Regarding the logical of autotools-utils_src_prepare, I think we would still require some changes in ebuilds because if the way we pass AUTOTOOLS_AUTO_DEPEND variable as, otherwise, once we start inheriting autotools.eclass, we start to get its DEPEND values. And, then, we probably should directly move to a new gnome2-r1.eclass (or gnome3.eclass) relying more in autotools-utils.eclass and also handling some old issues in a different way (like the ugly GCONF_DEBUG handling) -> but move this to bug #413299 :)
