Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: > On 04/26/2012 03:08 PM, Duncan wrote: >> Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: >>> Also, don't forget to consider the possibility of interference between >>> FEATURES=userpatch and epatch_user (applying same patches twice). >> >> The existing phaselock-file solution should continue to work there.
> Having the package manager interact with an eclass function like > epatch_user is ugly, and it's unnecessary since we can pull all of the > pieces into the package manager in EAPI 5. Any eclasses that currently > call epatch_user can have a conditional like this: > > if has $EAPI 0 1 2 3 4 ; then > epatch_user > else > apply_user_patches_here > fi But that doesn't solve the problem of making it globally available, since it only applies to packages/eclasses that already call epatch_user for EAPIs thru current EAPI-4. In ordered to make it globally available, it cannot simply be an EAPI-5 thing, it must apply to all current ebuilds whether they (or an inherited eclass) call epatch_user or not. Which means that conflict with the existing epatch_user is unavoidable, since it will either try to run twice where it's already called, or it won't run at all where it's not. Tho I guess one solution to that would be to change the name of the patches dir for the new version, calling it /etc/portage/patches2/ or some such. Another solution could be to make the existing epatch_user call a no-op, and force post-src-prepare invocation on EAPIs 1-4. But both of these have problems in that they nullify the work done in existing ebuilds to locate the call correctly, before eautoreconf or whatever. > >>> Overall, the "apply_user_patches_here" approach [1] seems pretty >>> reasonable to me. >>> >>> [1] >>> http://archives.gentoo.org/gentoo-dev/ >> msg_c228be85e0c4e577ad194e6004d59062.xml >> >> With the requirements that if the ebuild never calls it, it's still run >> immediately after source_prepare, thus ensuring that it gets called, >> AND that calling either autoreconf or eautoreconf without calling >> apply-user-patches fit is a repoman-checked error, it looks like it >> should work, agreed. > > I think it might be better to die if it's not called in src_prepare, > like Ciaran originally suggested. This ensures that people don't forget > to call it when they are supposed to. That can work for EAPI-5, but what about existing ebuilds? Remember, the goal is global coverage without forcing an edit to every existing ebuild that doesn't yet call it either directly or via eclass. >> But I'm a bit wary as to the robustness. And without a mechanism to >> apply the patches at a particular point (arguably, post-src-prepare) >> even in the absence of a specific apply-user-patches-here call, we're >> back where we were without a global solution, but if the >> hard-invocation is done, then we're back to either inefficiently >> running eautoreconf twice or forced into doing likely failure-prone >> detection, thus the worry over robustness. > > It's no worse than epatch_user currently is. It's the responsibility of > the person who overrides src_prepare to call eautoreconf or whatever > else when necessary, so the package manager will not have the burden. Except that in ordered to make it global without touching existing ebuilds, the PM MUST shoulder the burden. THAT is where the robustness issues appear. The require-it-in-EAPI-5-plus-only solution will help longer term, but given that many core packages are to remain EAPI-0 for the foreseeable future, that could be a VERY long term indeed. Additionally, it only makes user confusion WORSE, since a user still won't know for sure whether his patches will apply to a particular ebuild without looking. Making it "just work" is the goal, and just doing it for EAPI-5+ is nice, but not really sufficient. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
