From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A7FEB13888F for ; Sat, 17 Oct 2015 12:57:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6249321C077; Sat, 17 Oct 2015 12:57:05 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8A5CC21C005 for ; Sat, 17 Oct 2015 12:57:04 +0000 (UTC) Received: from [192.168.0.12] (aftr-37-201-215-34.unity-media.net [37.201.215.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 907C13408A6 for ; Sat, 17 Oct 2015 12:57:03 +0000 (UTC) Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] EAPI 6 draft for review To: gentoo-dev@lists.gentoo.org References: <22049.17676.1822.986579@a1i15.kph.uni-mainz.de> <20151017142418.006bc430.mgorny@gentoo.org> <56223EEE.1070903@gentoo.org> <22050.17536.189338.594956@a1i15.kph.uni-mainz.de> From: hasufell Message-ID: <5622459A.9040909@gentoo.org> Date: Sat, 17 Oct 2015 14:56:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 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 In-Reply-To: <22050.17536.189338.594956@a1i15.kph.uni-mainz.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 524c713b-c37b-4511-b047-a0c82828e595 X-Archives-Hash: 0a7b894422e9fab6d2d8ba47e7b89ddf On 10/17/2015 02:52 PM, Ulrich Mueller wrote: >>>>>> On Sat, 17 Oct 2015, hasufell wrote: > >>> 2. eapply_user really belongs in the PM, especially if it's run by >>> default. And it needs patch applying function. And if we have to >>> implement patch applying function anyway, we may as well make it >>> public to avoid unnecessary duplication. > >> Unreliable. The ebuild may define its own src_prepare function > > That eapply_user is called can be enforced by repoman, or by a QA > warning. > And still doesn't give sufficient control to the user. Documenting proper hooks is more useful. >> or the PM might define eapply_user as a no-op, which is valid as >> per PMS. > > Sure, it is implementation defined. Otherwise PMS would have to > specify all the details, e.g. where does the package manager look > for user-supplied patches and how are patch directories organised. > So either do it, or just remove it from EAPI=6.