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 1L9wh6-0007o5-3D for garchives@archives.gentoo.org; Tue, 09 Dec 2008 07:07:45 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6A991E060C; Tue, 9 Dec 2008 07:07:41 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 21D5DE060C for ; Tue, 9 Dec 2008 07:07:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id A56F565362 for ; Tue, 9 Dec 2008 07:07:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 required=5.5 tests=[AWL=0.652, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 h09MQBdNaPWS for ; Tue, 9 Dec 2008 07:07:32 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 91E1D6535D for ; Tue, 9 Dec 2008 07:07:31 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L9wgo-0002Dp-P6 for gentoo-dev@gentoo.org; Tue, 09 Dec 2008 07:07:26 +0000 Received: from ip68-230-99-190.ph.ph.cox.net ([68.230.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Dec 2008 07:07:26 +0000 Received: from 1i5t5.duncan by ip68-230-99-190.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 09 Dec 2008 07:07:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: EAPI 2 policy for portage tree Date: Tue, 9 Dec 2008 07:07:18 +0000 (UTC) Message-ID: References: <493DB50A.8090403@jmhengen.net> <1228781390.7351.2.camel@TesterTop3.tester.ca> <20081209001123.16281209@snowmobile> <1228782344.7351.5.camel@TesterTop3.tester.ca> <20081209002909.291758a0@snowmobile> <1228783422.7351.8.camel@TesterTop3.tester.ca> 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: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-99-190.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 35a9da03-75f5-4ce0-8ed3-a983f06cfe19 X-Archives-Hash: 7e69654dc9e48cc43f70971853ae132e Olivier Cr=C3=AAte posted 1228783422.7351.8.camel@TesterTop3.tester.ca, excerpted below, on Mon, 0= 8 Dec 2008 19:43:42 -0500: > I'm not suggesting waiting any longer, just not pushing ebuilds into th= e > tree until we have a stable enough version of portage that handles them > (and if we do, then lets mark it as stable..). FWIW this ~arch user's perspective: AFAIK, the policy is now that no EAPI is allowed to pass where the=20 corresponding version of portage is, stability-wise. That means, if a=20 portage supporting that EAPI is only available in overlays, ebuilds/ eclasses supporting it must also remain in overlays -- they can't be=20 added to the tree. (It's worth mentioning here that overlays aren't=20 restricted to portage features at all, some use features not in portage,=20 period, only in one of the other PMs.) Once a portage supporting that EAPI is in the tree, hard-masked for=20 testing, ebuilds using it may also be in the tree, but also hard-masked. Once a portage supporting that EAPI is in ~arch for testing, then ebuilds= =20 using it can likewise move to ~arch for testing, but they can't go stable= =20 yet. Only after a portage supporting a particular EAPI is stable can an ebuild= =20 requiring that EAPI stabilize as well. Note that in the above there's NOTHING stating that an ebuild that's in=20 ~arch for testing, cannot switch to an EAPI only likewise in ~arch for=20 testing. It's quite possible that such an ebuild still in ~arch will be=20 found to work better with features only in a new EAPI, and it's quite=20 legitimate in my opinion to change the ~arch ebuild (still testing,=20 remember) to require it, as long as a version of portage with support is=20 already in ~arch as well. Of course, by doing so the maintainer accepts=20 that he may not stabilize that ebuild until the supporting portage goes=20 stable as well, but if that's the case, there should be nothing blocking=20 an existing ~arch ebuild from being modified to require an existing ~arch= =20 portage, both of them still being in ~arch testing, after all. If people want to play with a few ~arch packages here or there, while=20 most of the system stays arch/stable, fine, but the choice and results of= =20 the choice should both be their responsibility. Maintaining devs=20 shouldn't have to worry about changing an ebuild that after all is still=20 in ~arch, if they judge it will ultimately make for a more stable ebuild=20 headed into stable. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman