From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1K6GVm-0006KK-Io for garchives@archives.gentoo.org; Wed, 11 Jun 2008 02:56:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 12592E0438; Wed, 11 Jun 2008 02:56:33 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id BDA75E0438 for ; Wed, 11 Jun 2008 02:56:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 55062667CE for ; Wed, 11 Jun 2008 02:56:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 required=5.5 tests=[BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejNTNRmi4hHI for ; Wed, 11 Jun 2008 02:56:26 +0000 (UTC) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by smtp.gentoo.org (Postfix) with ESMTP id 73DFB667FD for ; Wed, 11 Jun 2008 02:56:26 +0000 (UTC) Received: by wa-out-1112.google.com with SMTP id v33so2196219wah.24 for ; Tue, 10 Jun 2008 19:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent; bh=FiGYq75RVcS05RR/6GM769kDipX8Lu61/awQkhCuYh4=; b=xAHVo1EeBdsjjfXhy9C2oPGGavlVzPLv5zQ4+NVpBEY8JfWNfLVwm99DJ4UMJDrfVN nhe4OxOA2oirYHQFalwC4aGkH/GYL8PbpAqAD6ilujlO4nUuEnoumVmKG2zKQaCQA5ZL YSfY+4gm61TBUU/7pQizfKyPA269V/r8p9CYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=ch+nXSTipGjexTGFq8XUOEZRD5P6Yi1iHOxKpcufULqJ8UJOculTNNEigb2CfaAOou vEzNEwYSpGO6uJFSFnlUbTeKM9rQcyqBxqRzB4Wpge7Vyp02O7mA+0xxWesuEVKn/58a ght7J7mpsNrdS53Fp/gHRtkx8JbbN2InKEGXc= Received: by 10.114.66.8 with SMTP id o8mr5849452waa.169.1213152986029; Tue, 10 Jun 2008 19:56:26 -0700 (PDT) Received: from seldon ( [208.68.109.98]) by mx.google.com with ESMTPS id m26sm17562173pof.1.2008.06.10.19.56.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Jun 2008 19:56:24 -0700 (PDT) Date: Tue, 10 Jun 2008 19:56:23 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] extending existing EAPI semantics Message-ID: <20080611025622.GA9494@seldon.metaweb.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; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Archives-Salt: 2651f017-6de3-4243-a538-d27e8f8e5cb2 X-Archives-Hash: 5a75f34a6d083b25765eb676ca081286 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bit curious what folks opinions are re: conversion of eapi=20 requirements into a function, instead of a var. Essentially,=20 currently- """ #my ebuild. EAPI=3D1 inherit blah DEPEND=3Dmonkey funcs_and_such(){:;} """ pros: * simple, and was enough to get EAPI off the ground w/out massive=20 fighting (at least not WW3 level fighting) * works fine for metadata key level changes, function changes, etc. =20 I'm aware folks have stated "if DEPENDS changes, it won't be able to=20 handle it"- they're frankly wrong, they're confusing that post=20 sourcing EAPI is checked, *then* if EAPI is supported the metadata is=20 handled, else the manager is signaled that an unknown eapi was=20 encountered (essentially). Continuing... cons: * EAPI var must be set effectively before any invocations occur. * global scope invocations (inherit) must be eapi aware; * future additions to global scope invocations (say elib) will result=20 in an error spat by bash ("elib wasn't found"). * bash specific (which personally is fine to me, an ebuild is bash). * doesn't address versioning changes. Converting it into """ #my ebuild. eapi 1 inherit blah DEPEND=3Dmonkey funcs_and_such(){:;} """ with eapi effectively being eapi() { if [ "$1" =3D=3D 1 ] || [ "$1" =3D=3D 0 ]; return # we know this eapi, can handle it fi die "unsupported eapi $1" } pros: * same benefits as preexisting var approach. * via conversion to invocation instead of var setting (which is=20 untrappable), it's possible to bail the rest of the sourcing, thus=20 preventing any error msgs for unknown global invocations (elib fex). * easy to shoehorn in for any profile.bashrc compliant manager=20 (portage/pkgcore); realize paludis is left out here (via it=20 intentionally being left out of PMS atm by ciaran), but=20 profile.bashrc *is* used by ebuild devs, thus it's a viable course (I=20 don't see profile.bashrc ever going away basically). cons: * must be the first invocation. * bash specific (again, ebuild is bash, new format can do things=20 w/out having to worry about backwards compatibility). * doesn't address versioning changes. Basically, the proposal is an minor tweak of existing support- it has=20 the benefit of avoiding the filename complaints from folks and=20 addressing the usual "global scope invocation will breakzor in later=20 versions" complaint from paludis folk. It doesn't particularly provide for people shoving new versioning=20 components in, but frankly that's fine due to the mess having=20 versioning rules bound to EAPI would entail. After comments from folks, although if a responder is going to state=20 "filename is better!" skip it please, I already pointed out the diffs=20 (meaning bluntly, kindly skip repeating what has already been said). Cheers ~harring --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFITz7WsiLx3HvNzgcRAmheAKCuPchOWl+l9ASZsbR+AVli2sWskwCgw58w /7T9fdQeQ6nq1eLyRSBcMIs= =1WLa -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- -- gentoo-dev@lists.gentoo.org mailing list