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 1Lc2SX-0008Iw-2Q for garchives@archives.gentoo.org; Tue, 24 Feb 2009 18:56:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1F4ACE02B2; Tue, 24 Feb 2009 18:56:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D2719E02B2 for ; Tue, 24 Feb 2009 18:56:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 7489664B93 for ; Tue, 24 Feb 2009 18:56:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 required=5.5 tests=[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 tuDnegluYYLx for ; Tue, 24 Feb 2009 18:56:30 +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 457C164706 for ; Tue, 24 Feb 2009 18:56:29 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Lc2S6-0001Wu-Qt for gentoo-dev@gentoo.org; Tue, 24 Feb 2009 18:56:23 +0000 Received: from 142-165-95-83.msjw.static.sasknet.sk.ca ([142.165.95.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Feb 2009 18:56:22 +0000 Received: from dirtyepic by 142-165-95-83.msjw.static.sasknet.sk.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Feb 2009 18:56:22 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Ryan Hill Subject: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] =?utf-8?b?CVJlOg==?= Preliminary Meeting-Topics for 12 February 2009) Date: Tue, 24 Feb 2009 18:56:11 +0000 (UTC) Message-ID: References: <1234257125.18160.2016.camel@localhost> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> <49A26B84.7040006@gentoo.org> <1235383347.12908.0.camel@neuromancer.neuronics-tp.ch> <49A2B276.1000109@gentoo.org> <49A41D3F.4010706@gentoo.org> 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=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: main.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 142.165.95.83 (Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB5; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.2; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)) Sender: news X-Archives-Salt: d4da4641-097f-4d63-b1a7-f7878dee79b1 X-Archives-Hash: 896652340b28812e3ce9338b46ba9113 Alec Warner gentoo.org> writes: > Somewhat ironically, had everyone been less stubborn last year when > discussing this topic we could have embedded the EAPI in line X of the > ebuild in 2008 and be using it now; instead of still discussing it. > > I don't expect new novel ideas out of this thread. I expect the > council to defer it again because the arguments are the same as last > time and last time they were not convincing enough. I would prefer if > the council went one way or the other so that when we are arguing > about this in 2010 we can at least say "hey we have support in > $PACKAGE_MANAGERs for EAPI on line X since May 2009 so in 3 months we > can just switch. We don't have to make the switch; I'm just saying we > should add support to hedge our bets. > > Thoughts? Well I give up. There have been exactly zero technical arguments against GLEP 55 and plenty of rhetoric, but if that's enough to sway people then so be it. If we take EAPI extensions off the table, which of these would work the best (aka. gives people the warm fuzzies). - eapi in the file name, still ends in .ebuild -- no parsing needed -- doesn't allow version suffix additions/changes -- requires an initial wait period for PM's to implement support and be stabilized -- still makes some people grumpy/threaten to leave - eapi in the ebuild, on a predetermined line number -- error prone, restrictive -- doesn't require parsing -- doesn't allow version suffix additions/changes - eapi in the ebuild, anywhere -- what we have now -- currently requires sourcing the ebuild -- sourcing the ebuild requires knowing the EAPI -- doesn't allow version suffix additions/changes (actually, none of these do, so i'll stop repeating it) - eapi in the ebuild, before any other assignments/commands -- ie. if we hit inherit and no EAPI is defined, EAPI=0 -- restrictive (eapi must be a direct assignment, no conditionals, etc) -- no per category/PN eapi's or eapi's set in eclasses -- probably the next best solution (IMUO) - eapi in metadata somewhere else -- meh, i'll let the proponents of this argue for it please fill your arguments for or against, or fix whatever i have wrong. some other random ideas i've seen tossed around: - #!/bin/env eapi-parser - split EAPI into EAPI and some separate counter which would only be incremented on uncompatible changes to the ebuild format - change .ebuild to .eb - waffles (sorry, lunchtime)