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 1SNWsd-0001bB-AG for garchives@archives.gentoo.org; Thu, 26 Apr 2012 22:09:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0EA1DE0618; Thu, 26 Apr 2012 22:09:15 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 520CAE05EB for ; Thu, 26 Apr 2012 22:08:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id D76571B4030 for ; Thu, 26 Apr 2012 22:08:46 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5.5 tests=[AWL=-0.597, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ap9Zey0fZXV for ; Thu, 26 Apr 2012 22:08:40 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 6D5A91B402E for ; Thu, 26 Apr 2012 22:08:40 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SNWrb-0004n4-Ma for gentoo-dev@gentoo.org; Fri, 27 Apr 2012 00:08:35 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Apr 2012 00:08:35 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Apr 2012 00:08:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Making user patches globally available Date: Thu, 26 Apr 2012 22:08:25 +0000 (UTC) Message-ID: 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> 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 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.136 (I'm far too busy being delicious; GIT 187e40f /st/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e4f595ab-7d79-4237-ab4a-818ee7f45533 X-Archives-Hash: 384ce0d20c4537bf0ba3384857d62dcf Zac Medico posted on Thu, 26 Apr 2012 08:21:02 -0700 as excerpted: > On 04/26/2012 02:55 AM, Duncan wrote: >> Zac Medico posted on Wed, 25 Apr 2012 23:26:24 -0700 as excerpted: >> >>> On 04/25/2012 11:18 PM, Duncan wrote: >>>> IOW, let's quit letting the perfect be the enemy of the good >>> If that means settling on something that's fragile and prone to lots >>> of bug reports, then it's not really practical >> IMO[,] If all it does is the patching, but it /always/ does the >> patching[,] and people know they need to use the overlay-ebuild >> method to do anything beyond patching, [including eautoreconf,] >> then it should "just work". > Ignoring the problem doesn't make it go away. If we ignore the problem, > then we end up dealing with bug reports of the form "FEATURES=3Duserpat= ch > doesn't work with this particular patch set" until the end of time. Standard boilerplate resolved/DUP, pointing to the first one, resolved=20 like this: NOTABUG/INVALID. The feature does what it says on the label and is=20 working as designed. The files are patched and the build bails out if=20 the patch fails. The userpatch feature is deliberately limited to=20 patching, thus keeping the problem manageable and the code transparent=20 and maintainable. For anything fancy, including patches that need=20 eautoreconf called afterward, the userpatch feature isn't the right=20 tool. Copy the ebuild to an overlay and edit it as necessary to both=20 apply the patch and eautoreconf or whatever else needs done afterward. > Also, don't forget to consider the possibility of interference between > FEATURES=3Duserpatch and epatch_user (applying same patches twice). The existing phaselock-file solution should continue to work there. Test= =20 for the existence of a file and punt if it's found; touch the file on=20 first invocation. The only caveat is that the existing eclass solution has changed the=20 filename before. Once the corresponding feature exists, both the eclass=20 and the feature will have to use the same filename so as not to conflict=20 with each other, thereby effectively locking down the name and preventing= =20 further changes to it. > Overall, the "apply_user_patches_here" approach [1] seems pretty > reasonable to me. >=20 > [1] > http://archives.gentoo.org/gentoo-dev/ msg_c228be85e0c4e577ad194e6004d59062.xml With the requirements that if the ebuild never calls it, it's still run=20 immediately after source_prepare, thus ensuring that it gets called, AND=20 that calling either autoreconf or eautoreconf without calling apply-user- patches first is a repoman-checked error, it looks like it should work,=20 agreed. But I'm a bit wary as to the robustness. And without a mechanism to=20 apply the patches at a particular point (arguably, post-src-prepare) even= =20 in the absence of a specific apply-user-patches-here call, we're back=20 where we were without a global solution, but if the hard-invocation is=20 done, then we're back to either inefficiently running eautoreconf twice=20 or forced into doing likely failure-prone detection, thus the worry over=20 robustness. But of course he who codes, decides. We have existing and already proven= =20 code for the simple case, but if someone actually codes that complex=20 approach, and it actually does both get us global coverage and avoid=20 duplicated autoreconf runs, without hard to track down failures, I for=20 one will certainly bless them! =3D:^) I just don't want to have to wait until kingdom come for the "perfect"=20 solution, when we already have a demonstrated "good enough 80-90% of the=20 time" solution ready to roll out globally, if we'd just do it. It's also worth pointing out that nothing prevents rolling out the "good=20 enough" solution right away, then growing the complexity to cover the=20 harder autoreconf cases when a solution for them actually gets coded. --=20 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