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 1LcUAh-0004h9-Uf for garchives@archives.gentoo.org; Thu, 26 Feb 2009 00:32:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D26F5E0330; Thu, 26 Feb 2009 00:32:13 +0000 (UTC) Received: from mail-fx0-f175.google.com (mail-fx0-f175.google.com [209.85.220.175]) by pigeon.gentoo.org (Postfix) with ESMTP id 7A475E0330 for ; Thu, 26 Feb 2009 00:32:13 +0000 (UTC) Received: by fxm23 with SMTP id 23so242150fxm.34 for ; Wed, 25 Feb 2009 16:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=FpLRwkPDhTsu1cubQQUfRs+yfU+094fOMm1JhIAX3HA=; b=kKQorStQok2XQQG+rKARdZUcHy6BzwPSEuaEvI6Ci5YiGZ5qAnM6mpNoIll3V8tSF8 Qub6aud8anbMgWH4PxQWUeQIkktE1cy0B5rQaDz4TFLfrDDtujkndnB0WSiY2bDgVgAA fL3NNePjWXGr3sT+HFE1Fh7D0CEOZCeo+qrp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=G4l/CUvSYhY4I3jR0Qic9BQPz+v5cjXT8ax74V/p6Ux7FToxvTObPVVY644kH/TVKh ntcnaDeAVYxK4Zeiictm0r9avKI0q7bClBsSBkOEogT+3ebhmkkdjG8imgWoaJF4/Tyf QyQT4GrHv42Ep7pKldneSGqIEI6hb/U/eVv7c= Received: by 10.223.114.207 with SMTP id f15mr1481603faq.90.1235608332848; Wed, 25 Feb 2009 16:32:12 -0800 (PST) Received: from snowmobile (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id d26sm7200260nfh.8.2009.02.25.16.32.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 16:32:12 -0800 (PST) Date: Thu, 26 Feb 2009 00:32:03 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eapi function (Was: Collecting opinions about GLEP 55 and alternatives) Message-ID: <20090226003203.5ee525d8@snowmobile> In-Reply-To: <20090226002445.GL3506@hrair> References: <49A472E3.1010204@gentoo.org> <20090225124951.GD3506@hrair> <20090225230307.33c9f4f8@snowcone> <20090226000246.GK3506@hrair> <20090226001104.3cec09e5@snowmobile> <20090226002445.GL3506@hrair> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; i686-pc-linux-gnu) 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="Sig_/a9Or35=c.f7x+LOSgDFZIbh"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: aa11f0c3-bdae-4f60-8bc0-4798773e946e X-Archives-Hash: 340e1d3bdbfe9f161d7fa8ee381ee74b --Sig_/a9Or35=c.f7x+LOSgDFZIbh Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 25 Feb 2009 16:24:45 -0800 Brian Harring wrote: > > You can do that on a variable assignment too, with all the same > > implications as having it as a function, and a slightly less > > horrible upgrade path. >=20 > You're contradicting your own statements. Pkg level eclasses (if=20 > reusing inherit) would explode 'in a user visible manner' if using > var only. No, if we're shoving retroactive changes into existing EAPIs (as would be done for making eapi a function), we could instead say "EAPI must be assigned to only once". That has *exactly* the same implications as having it as a function, except that the upgrade path is cleaner because there's no need for the horrid global scope die to work around existing package managers. > > Which is a "wait a year or more" thing... If you do it with a > > variable instead of a function, you can at least roll out EAPI 3 > > (without any global scope changes, but with the stricter "stop on > > setting an unsupported EAPI" requirement) without the wait. >=20 > There is no reason to wait a year let alone wait for EAPI3 to be=20 > defined. The eapi function could be added now in preparation (thus=20 > killing the user visible pukage), regardless of eapi 3's timeline. >=20 > The die exists strictly to be thorough about stragglers. But there's no need for the die if you do it on a variable instead of a function. > > > Every proposal has uglyness- g55 for example doesn't give the user > > > any indication that they're not seeing ebuilds due to EAPI (in > > > other words loss of functionality that exists now). > >=20 > > Given you're a proponent of not showing users things that're merely > > masked... >=20 > Say what you want; g55 still has the flaw. Any sane package manager can, immediately upon a new EAPI being defined, do a stable release updated with minimal information about the new EAPI to enable it to show up as being there but not supported, even if full support needs a new major version and lots of ~arch testing time. --=20 Ciaran McCreesh --Sig_/a9Or35=c.f7x+LOSgDFZIbh Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkml4wYACgkQ96zL6DUtXhFsBACfS/jWZjbzhCPLGOK/BEz9s6qx 18MAoJd+DrDlZMB5OU2ukauf6hMkdHr1 =Fofh -----END PGP SIGNATURE----- --Sig_/a9Or35=c.f7x+LOSgDFZIbh--