From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-66233-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6345913877A for <garchives@archives.gentoo.org>; Sun, 15 Jun 2014 13:30:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 15F6AE0BEC; Sun, 15 Jun 2014 13:30:23 +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 DD0DAE0B21 for <gentoo-dev@lists.gentoo.org>; Sun, 15 Jun 2014 13:30:21 +0000 (UTC) Received: from pomiot.lan (static-81-219-255-132.devs.futuro.pl [81.219.255.132]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 975EC33ECA5; Sun, 15 Jun 2014 13:30:19 +0000 (UTC) Date: Sun, 15 Jun 2014 15:30:10 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= <mgorny@gentoo.org> To: gentoo-dev@lists.gentoo.org Cc: rich0@gentoo.org Subject: Re: [gentoo-dev] Eclass vs EAPI For Utility Functions (Patching/etc) Message-ID: <20140615153010.173d2ff3@pomiot.lan> In-Reply-To: <CAGfcS_kix1enpz4uwj5tO-Qeeqrp=8tKWjdMiC1QuUR-g8R4Tg@mail.gmail.com> References: <CAGfcS_kix1enpz4uwj5tO-Qeeqrp=8tKWjdMiC1QuUR-g8R4Tg@mail.gmail.com> Organization: Gentoo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/dncCgk+IjrqAu7fXOPxXwRY"; protocol="application/pgp-signature" X-Archives-Salt: 8a8131cb-9422-42e9-8dd8-ab28a0268d8a X-Archives-Hash: c60d0db7078f86f67fb97397150d8a6c --Sig_/dncCgk+IjrqAu7fXOPxXwRY Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-06-15, o godz. 07:00:15 Rich Freeman <rich0@gentoo.org> napisa=B3(a): > 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. 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. 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. Now, for the overall point. I think there are a few cases when you want something in the PM: 1. when it's a common thing to do that doesn't require repository- specific details like relying on some out-of-@system packages, 2. when it requires specific interaction with the package manager, 3. when it is required by some other PM-specific code. Keeping it 'internal' just means having duplicate code between PM and eclasses. 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. 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. 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 -- putting more commonly used stuff to EAPI so that many of eutils inherits could be removed. I don't have the numbers but I'd dare guess inheriting eutils everywhere does come with some overhead on metadata cache generation. As far as both eapply & eapply_user are concerned, I believe they both belong to the group of commonly used functions, so they ought to go into PM wrt (1). Moreover, eapply_user pretty much requires you to provide a location for the patches -- and putting /etc/portage into an eclass is just wrong. Of course, we could try some new, fancy location but well... I'd rather keep it as-is and consider it PM-specific, so argument (2). And if put eapply_user anyway, argument (3) says we gotta add eapply as well, or otherwise we'll be using two similar functions all the time -- one in the PM, the other in the eclass. --=20 Best regards, Micha=B3 G=F3rny --Sig_/dncCgk+IjrqAu7fXOPxXwRY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJTnZ/iXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOZ5gP/j0GonGADVFgMzdJMFAf0XCx 2rJmdk6lExkqUKLRYHROj/SQdFTRhcv/v3ev7k2J+i5S77sEn9ghu23CmOzmMAq4 5atrt2DvJunoG5wQaFjUB8LQKBX8YLuEMaLXkEvwWig9hCg/dcTxtrhpRDHiw9FO 7zh0sIniHYrsuhsGWaIq0mwqv9hu82aQNSpiqcGucpachhMwetEOT0he9qNpd2rl 9pjnzpLoAOtfQUSt5k8WBnT504gzH2nSZ8a7An3X4MlSQIeW/0ADX5cJu49TzCpP AO5IxYrCxFLpCXfFr/a+BFmtP4iCEyXxDMK1yhg2eWszfIEgdVfi79dmZtWfrBdT 9c0jDge/aQluGDH+lpZNfZMEKkQfVRkWLzYK1qzDBA9stiE8AnsDg+L7pZ961WNK vUUO8mX4AbyUPSwfVUr0cINGlOPl4RC7dWnayl5LdI6GVfC89Mj8TN7yBb7Xi33q sJ6D1OMdOY0Hl9e8sUDhhe2A4s29EsiqbULwCJQCfwRCqkVsPVhBNLVfrq+70kiX 1Vzn0lt6LCLA5lu/dU4gH173HReHHw/sQhNJylDJKwnwLs2rm/UCmVVsIw4xtaG+ +4KUND8+Yp/2YJeE+D/C9wlF+3ImW918//bkRHiQJ2IrHzhch2n+AC3PnMMk6HiV aLFCStXO9GkLTg9b6UmI =iXVR -----END PGP SIGNATURE----- --Sig_/dncCgk+IjrqAu7fXOPxXwRY--