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 1SNo0N-0005lE-56 for garchives@archives.gentoo.org; Fri, 27 Apr 2012 16:26:47 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D3B2D21C030; Fri, 27 Apr 2012 16:26:28 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id CDB2E21C02C for ; Fri, 27 Apr 2012 16:25:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 600221B4006 for ; Fri, 27 Apr 2012 16:25:14 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5.5 tests=[AWL=-0.248, BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.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 eUtIdA1bs621 for ; Fri, 27 Apr 2012 16:25:08 +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 A36671B400B for ; Fri, 27 Apr 2012 16:25:07 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SNnyi-0006mG-8q for gentoo-dev@gentoo.org; Fri, 27 Apr 2012 18:25:04 +0200 Received: from athedsl-353203.home.otenet.gr ([85.72.235.81]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Apr 2012 18:25:04 +0200 Received: from realnc by athedsl-353203.home.otenet.gr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Apr 2012 18:25:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Nikos Chantziaras Subject: [gentoo-dev] Re: Making user patches globally available Date: Fri, 27 Apr 2012 18:55:12 +0300 Organization: Lucas Barks 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> <4F99F941.90705@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; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: athedsl-353203.home.otenet.gr User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120330 Thunderbird/11.0.1 In-Reply-To: X-Archives-Salt: 4cdbdb9a-9e96-43c8-abef-10708731ecf7 X-Archives-Hash: e1b1542a55d846850a105c275b184d4a On 27/04/12 17:15, Duncan wrote: > Zac Medico posted on Thu, 26 Apr 2012 18:41:21 -0700 as excerpted: >> 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. According to the source, calling it twice is perfectly safe.