From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SNaCS-0000u2-7h for garchives@archives.gentoo.org; Fri, 27 Apr 2012 01:42:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2EC59E071E; Fri, 27 Apr 2012 01:42:05 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id CDBD6E058A for ; Fri, 27 Apr 2012 01:41:24 +0000 (UTC) Received: from [192.168.42.186] (staff-wireless.saddleback.edu [209.129.85.50]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 4EC571B400B for ; Fri, 27 Apr 2012 01:41:24 +0000 (UTC) Message-ID: <4F99F941.90705@gentoo.org> Date: Thu, 26 Apr 2012 18:41:21 -0700 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120404 Thunderbird/11.0.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Making user patches globally available References: <20120415021641.1858ffde@gentoo.org> <4F8A885C.3050508@gentoo.org> <20120418185913.3d2fa68f@epia.jer-c2.orkz.net> <201204181340.00474.vapier@gentoo.org> <20120418184138.50153e57@googlemail.com> <4F8F05E9.5070103@gentoo.org> <4F8F0929.2010109@googlemail.com> <4F8F18EC.3000707@gentoo.org> <4F8F3513.2060202@googlemail.com> <20120425224433.2fa0f2de@gentoo.org> <4F98EA90.4000403@gentoo.org> <4F9967DE.8000601@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 8624cc75-c4d7-410f-9065-dff033adefb9 X-Archives-Hash: e782edd84a7857c9316645cab424a367 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. Test > for the existence of a file and punt if it's found; touch the file on > first invocation. > > The only caveat is that the existing eclass solution has changed the > filename before. Once the corresponding feature exists, both the eclass > and the feature will have to use the same filename so as not to conflict > with each other, thereby effectively locking down the name and preventing > further changes to it. 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 >> 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 first 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. > 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. -- Thanks, Zac