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 4C2EE13800E for ; Fri, 27 Jul 2012 17:57:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4E6AAE0605; Fri, 27 Jul 2012 17:56:58 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 55CD9E062C for ; Fri, 27 Jul 2012 17:56:08 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id C43EE1B4065 for ; Fri, 27 Jul 2012 17:56:07 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] epatch still no helper function? [from eutils.eclass] Date: Fri, 27 Jul 2012 13:56:07 -0400 User-Agent: KMail/1.13.7 (Linux/3.5.0; KDE/4.6.5; x86_64; ; ) References: <5006D73E.2070704@gentoo.org> <3547364.aZtTPijkF8@grenadine> <20120718182941.5444bfcc@googlemail.com> In-Reply-To: <20120718182941.5444bfcc@googlemail.com> 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: multipart/signed; boundary="nextPart1595539.UPFSGvzj20"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201207271356.07985.vapier@gentoo.org> X-Archives-Salt: c98d38c1-8189-4e5c-bf17-56831e31eb51 X-Archives-Hash: fed6b58fdeecd0da7c91064df9c3f6f5 --nextPart1595539.UPFSGvzj20 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wednesday 18 July 2012 13:29:41 Ciaran McCreesh wrote: > On Wed, 18 Jul 2012 18:18:35 +0200 "Andreas K. Huettel" wrote: > > > On Wed, Jul 18, 2012 at 5:33 PM, hasufell > > >=20 > > > wrote: > > > > "epatch" is so widely used and basic that I wonder why it's still > > > > not implemented as a real helper function. > > >=20 > > > Because then its harder to change, it must be in PMS, otherwise you > > > have to do things like test which version of epatch the package > > > manager provides....sounds a lot like EAPI :) > >=20 > > You know, that's actually a pretty good case *for* base.eclass, > > eutils.eclass and similar... we should probably move more functions > > there... :D >=20 > I'm not sure that having to make sure you don't break ten thousand > packages whenever you make a change is a good case... When it's EAPI > controlled, if a change causes problems, it doesn't break anything. and the obvious con is that it's hard to add new features and extend=20 implementation details without also upgrading all EAPI aspects. locking do= wn=20 EAPI is great for the format of the file and for simpler commands (like mos= t of=20 the install funcs), but for more complicated functions, an eclass is nicer. =2Dmike --nextPart1595539.UPFSGvzj20 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJQEtY3AAoJEEFjO5/oN/WB1lQP/RsfHaWq+AdNJ/WZzp1GKeQS hyB4x0k5QKjVnd/RMe29pCczlefNBAPWUJ+2OtnyYGHK3EA3ZNKzVnQDt44XY+hq NqS7GqCx6jMCbkZ6gobzQqgZc0SzVdPGCElSmMVfQDmXih9SJP+PaukPaowoXDAm RjU0KugFa0EoSbz0yT+06/Vj8JACE0mER72O9ApMXxmcUK9EiInXlWdbcOStfsP8 ScaZVCf1psRiQ1NLrwQ47pD8eKLxPA84sPg3w5uiusnr0vMuXIJGklvJWXHmZqWs dpJO6JHu5qg/0w/tFzEIPmz2E7dOVGdP8jdwoy/r7PhGq2h851k4WMA3h8Fobp3y gbrnMSNhB08Mw7iJu1OAnqcp846guyNrZCfWrk4uRfDCA0AVW+7ESUCrgBCaV6ph HVIiqFDfmFy/bD0/HfOUGdbrraYYNV3+ytXjvg/BkBhLkyJCFPGG+1DSExlbgOxL YTPcvVeDtHOBf/fWiTdOfzwmQvvt6iZPrLuX4tNQ+mD2k8feVsfFEbzhfqJk3utT WOcDdR0w7Ge1v67FbJ3dmHvgSUCXHHY4A8mjw0nJOwubNYfz8WVHDZhvG4pNnMv9 WQ7gYCwgeJUzt8HeBvC8LBTTFBgxXHk2dl//MsOfM6dOd5+QVs8D3Vu/8+3vwPw1 J1L9/xb5a7fmH4T4lTZU =0fQj -----END PGP SIGNATURE----- --nextPart1595539.UPFSGvzj20--