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 9F0DD13888F for ; Sat, 17 Oct 2015 12:49:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7DD2D21C04D; Sat, 17 Oct 2015 12:49:44 +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 8536421C01E for ; Sat, 17 Oct 2015 12:49:43 +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 1315634089F for ; Sat, 17 Oct 2015 12:49:40 +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> <56223E25.1090407@gentoo.org> From: hasufell Message-ID: <562243E0.509@gentoo.org> Date: Sat, 17 Oct 2015 14:49:36 +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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 8e3e5b91-4735-4745-aebd-7a103a8a91df X-Archives-Hash: c732e7868e1d099e3e696837dadc23d8 On 10/17/2015 02:38 PM, Rich Freeman wrote: > On Sat, Oct 17, 2015 at 8:25 AM, hasufell wrote: >> On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote: >>> >>> The other question is more critical -- could you merge eapply and >>> eapply_user? Or add some hook to PMS so that eapply_user isn't needed? >>> IOW, it'd be nice if every package was, by default, patchable by the user. >>> >> >> IMO, eapply_user should not be in the eclass and not in PMS. patches are >> something that can easily be done via PM hooks, if the PM has proper >> hooks support. >> > > The reason this was done was to give maintainers more control over > WHEN patches are applied, while still ensuring they are applyied. > You can apply the patches post_unpack or post_src_prepare witht hooks. What's the problem? Maintainers might forget to add it, add it in the wrong order or the PM doesn't support it. So people who want consistent patch support already HAVE to use hooks and that will not change. So you could as well remove eapply_user/epatch_user altogether. > The other feature that is supposed to be in EAPI6 (I didn't read the > draft yet) is that the PM should refuse to install the package if > eapply is never called (ie src_prepare is overridden and the ebuild > didn't call eapply). It is required that all ebuilds call it once > unconditionally. That way users don't get inconsistent behavior from > package to package and be dependent on maintainers to fix it. > I hope that "feature" doesn't make it into EAPI6.