From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M5lYC-0008AZ-67 for garchives@archives.gentoo.org; Sun, 17 May 2009 18:57:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 02E01E03B6; Sun, 17 May 2009 18:57:31 +0000 (UTC) Received: from mail.goodpoint.de (tori.goodpoint.de [85.10.203.41]) by pigeon.gentoo.org (Postfix) with ESMTP id C393CE03C4 for ; Sun, 17 May 2009 18:57:30 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rbu) by mail.goodpoint.de (Postfix) with ESMTP id 81C3310BA75 for ; Sun, 17 May 2009 20:57:29 +0200 (CEST) From: Robert Buchholz To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] GLEP 55 updated Date: Sun, 17 May 2009 20:57:25 +0200 User-Agent: KMail/1.9.9 References: In-Reply-To: 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="nextPart3130881.s69Ma7V2aR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200905172057.27149.rbu@gentoo.org> X-Archives-Salt: d24d5242-d21e-4a8e-91ee-0523032a6171 X-Archives-Hash: bc1ac7cd36bebb105aabd0b1befb118c --nextPart3130881.s69Ma7V2aR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 17 May 2009, Piotr Jaroszy=C5=84ski wrote: > Hello, > > I have just updated GLEP 55 [1], hopefully making it a bit clearer. > > Just FYI, my order of preference of solutions is: > > 1. EAPI-suffixed ebuilds (obviously) > 2. EAPI in the filename with one-time extension change > 3. Easily fetchable EAPI inside the ebuild and one-time extension > change Judging from this list, fourth option present in the GLEP is=20 unacceptable for you? 4. Easily fetchable EAPI inside the ebuild =46rom what I understand, the difference between 3 and 4 is that (4) would break pre-glep55 Portage versions that see an ebuild with no metadata cache present if the ebuild uses a future EAPI that=20 introduces changes as described in the "Current behaviour" section. (4) would otherwise keep the current workflow the same except=20 restricting the way the EAPI variable is defined in the ebuild. I would argue that most people who are be exposed to repositories that=20 do not carry a metadata cache (overlays) which use new EAPIs also keep=20 their portage version current. I'd say go with option (4) now and by=20 the time EAPI 4 is collected, written up, agreed upon and implemented,=20 enough time went by so we would not have to introduce an artificial=20 delay. And after that, there won't be any delay to avoid breakage anymore. Robert --nextPart3130881.s69Ma7V2aR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iQIcBAABCAAGBQJKEF4XAAoJECaaHo/OfoM5gnYP/RpW+Wl6uSg5s4g0ojz/XkIu fzFsfH/kk2E3XEOj/AVGL/sRQOoxqGlAFNMl+rKtK9DM4N/Y4QO6R9oPWfJlRMNy uS6+1keFbKKva/L++sQWMH8LicRMtbywwjrOlU+6Ma5ZmxC8VXrvJHfUw394UI3P HQVUKgHF1PJG78FjOyeDcHF1RxvwwBZWqCZNnJKUyzf9rwL0v/U9AKcNwbroLRXh wLue8eZh9+f/dURdmRrJlr4Nm5u6efOgRE222LoA1D3VdUeh/clb3wC7D6eYYfUY LKdQCMsnggvxXUxRzujwd71uCVvnyO8nyEc3QibSoAkyAg19IVjh7e2WBkMTYJEo ffVSp/LEJ1hzSAQznKqSwNY1XwZvdEEF56vIuW3YS473wrwXwAOe14enuJ5UIjpi rKUedtTYyCZAIBq+3G619n/g4CdUjyP2clRDlADgu0On0CXAh9pFbJd3oi9y3k+o qi2W6q1/CwQ5ElfQDcf8Zkm8vaArlSFgHml0HTehUyKdDVgC0Zf/+JUjrHz9z/SZ RPYNkmuzWx6Fxw3qUeOtoXTWqlx9rj04DvcpZz4TnFnLkGygt8ODpgeSUUAwjkD9 7S67nLgzFK5nVLTY6D4SjuvVLKmhE/1tTjbHjpBQKw09hxdPXub4k2l9dQhdFekz rKvw4waQ9OnEQYEm3SIG =77r4 -----END PGP SIGNATURE----- --nextPart3130881.s69Ma7V2aR--