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 0283113877A for ; Thu, 19 Jun 2014 21:42:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1A204E08EC; Thu, 19 Jun 2014 21:42:11 +0000 (UTC) Received: from smtpout.karoo.kcom.com (smtpout.karoo.kcom.com [212.50.160.34]) by pigeon.gentoo.org (Postfix) with ESMTP id E73D1E0852 for ; Thu, 19 Jun 2014 21:42:09 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.01,509,1400022000"; d="scan'208";a="74679794" Received: from unknown (HELO rathaus.eclipse.co.uk) ([109.176.198.98]) by smtpout.karoo.kcom.com with ESMTP; 19 Jun 2014 22:42:10 +0100 Date: Thu, 19 Jun 2014 23:05:40 +0100 From: "Steven J. Long" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Re: Eclass vs EAPI For Utility Functions (Patching/etc) Message-ID: <20140619220540.GD4582@rathaus.eclipse.co.uk> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20140615153010.173d2ff3@pomiot.lan> 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 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20140615153010.173d2ff3@pomiot.lan> X-Archives-Salt: 9aeb3305-0479-4bcb-b53c-3d6968df9342 X-Archives-Hash: 02d9aec1fe71ae930ea89605922412a8 On Sun, Jun 15, 2014 at 03:30:10PM +0200, Micha=C5=82 G=C3=B3rny wrote: > Dnia 2014-06-15, o godz. 07:00:15 > Rich Freeman napisa=C5=82(a): >=20 > > 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. >=20 > I think this point is a bit tangential. While eclasses are the obvious > way of having code common between package managers, I don't think > sharing code should be an argument for putting something in an eclass. Er, it's the most fundamental argument for using an eclass. Thought not between package managers, since they don't factor into the equation, so long as they provide EAPI conformance (theoretically.) > Please remember that you can create your own base repository without > having 'gentoo' as master. Then, putting code in eclasses actually > requires you to duplicate it -- unlike code in PM which is shared > between all repos. Well that's an argument for certain base functionality being in the PM although I'd note that "in the PM" in most cases, and this one, means "in ebuild.sh or one of its associated BASH modules." It's not an argument for sharing script across ebuilds in general, by putting it in the the context for every ebuild. As for different master repos, that's an appropriate discussion at at the package-manager code level, but not at the distro level, imo. > Now, for the overall point. I think there are a few cases when you want > something in the PM: >=20 > 1. when it's a common thing to do that doesn't require repository- > specific details like relying on some out-of-@system packages, >=20 > 2. when it requires specific interaction with the package manager, >=20 > 3. when it is required by some other PM-specific code. That's enforced by the requirement. > Keeping it > 'internal' just means having duplicate code between PM and eclasses. No: it also means you don't expose it until it's needed. The worst thing in the world is having to rely on variant behaviour according to the phase of the moon, which is about what you get when internal APIs are exposed without cause and consensus. Since you're speaking in general terms. > I think the only debatable thing here is (1). If we ever decide that > having common stuff in an eclass is feasible, we ought to move all > the common stuff that's possible -- including econf, emake, possibly > some install helpers. I'm not sure what that's got to with out-of-@system packages, but it sounds like a bad idea, and counter to your argument about sharing code via the PM, and not eclasses. > This may even have more benefits than that. For example, you would fit > the implementation to specific system -- like 'gentoo' repository > eclass would be fit for Gentoo-specific tools. Instead of putting > requirements for a system in PMS and trying to fit PM and profiles > together, we'd just use whatever the repository provides. That sounds insane to me. What happened to reproducible builds? Let alone a robust user experience. Perhaps at the package-manager code level, but not at the distro level. And it's the Gentoo PMS, so I don't see any conflict. Though this appears to be the same "tangent" Rich brought up. > Of course this brings another argument -- every single ebuild would > have to source a specific eclass. For EAPI 6, I've focused on going > the opposite way So which way do you actually prefer? You appear to be arguing for, and implementing, common code by EAPI, in the rest of your mail. Since that's always been the point of them, based on developer consensus about what is truly essential, and what is only needed for a subset of the tree, that's fine by me. Just so long as they are essential, and you do have consensus on that. > As far as both eapply & eapply_user are concerned Why can't we just have epatch and upatch? =3D I'm on record as wanting this in the PM, btw, back when we were discussing how it should deal with patches not being applied. --=20 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)