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 1015E13877A for ; Mon, 16 Jun 2014 09:54:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E5777E0D26; Mon, 16 Jun 2014 09:54:20 +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 D9DE0E0D07 for ; Mon, 16 Jun 2014 09:54:19 +0000 (UTC) Received: from [192.168.1.33] (198.Red-2-137-229.dynamicIP.rima-tde.net [2.137.229.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id 649CE33FDF1 for ; Mon, 16 Jun 2014 09:54:18 +0000 (UTC) Message-ID: <1402912454.2466.10.camel@belkin5> Subject: Re: [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc) From: Pacho Ramos To: gentoo-dev@lists.gentoo.org Date: Mon, 16 Jun 2014 11:54:14 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.3 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-Transfer-Encoding: 8bit X-Archives-Salt: adfd3644-179d-4cac-ae48-c1e083066d77 X-Archives-Hash: 115cfee1ba8bf71d7b0fc72321173db4 El dom, 15-06-2014 a las 07:00 -0400, Rich Freeman escribió: > I debated where to post this, but the topic is fairly dev-oriented and > has big long-term impact so I landed here. This really isn't > organizational in nature. > > During the council meeting there was a bit of a philosophical debate > over the proper role of EAPI vs implementing functions in eclasses. I > felt that it was important enough to at least get more community input > before we continue voting on features like user patching/etc which > tend to favor an EAPI-based approach. > > I'll try to fairly frame the arguments, though I personally lean in > the EAPI direction and I'll leave it to somebody else to fix my straw > man. > > > The Eclass argument goes like this: > Eclasses already work in every PM. Half of what we're debating is > already in eutils. Why move this code into the PM, where it has to be > re-implemented everywhere? If anything we should be moving more PM > functionality out and into eclasses where we can have competing > implementations and more flexibility. > > > The EAPI argument goes like this: > Sure, you can have 14 different implementations of epatch which lets > each maintainer use the one that makes the most sense. However, who > wants to edit an ebuild which uses a "bad" epatch implementation and > re-learn how to add a patch? Adding patches is a common thing, so why > not have a standard way to do it? We can still have eclasses for > one-offs. And how can you ever do something like user patches when > they will only work if the maintainer cares to support them? > > > I view this as not being unlike dealing with programs that encourage > the use of Turing-complete configuration files. Sure, they give you a > lot more power, but that power comes at a cost. Sendmail config files > are a running joke, and if you want to control the niceness or > ioniceness of an OpenRC service then you're going to have to read the > script and possibly patch it. > > When there is no value in everybody doing things differently, why not > just do them the same way? > > Besides, I think user-patches are a GREAT feature to have, and one I > use all the time (without even thinking about it if a package with a > patch gets rebuilt). As I said in the meeting, if we were selling > Gentoo to make money, it would be the sort of feature that you'd > advertise. Why make it hard to use such a distinctive advantage of a > source-based distro? > > Since this month is the last one for this Council term as an added > bonus you stack the next Council with folks who agree with you on this > one... :) > > Rich > In this concrete case we the benefit I see for having support for epatch_user/eautoreconf at EAPI level is that we won't need to implement that support on each ebuild/eclass or need to manually overwrite default phases for them inheriting, for example, autotools-utils.eclass to reuse its patches handling. Other option would be to have two kinds of eclasses, one of them would be inherited *always* and always being used, but I am not sure if adding this new "layer" could complicate things a bit more :/. This kind of eclasses would be used always and would allow to backport some features to older eapis.