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 1S668c-0005Qy-PN for garchives@archives.gentoo.org; Fri, 09 Mar 2012 20:10:07 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C92DDE07C7; Fri, 9 Mar 2012 20:09:57 +0000 (UTC) Received: from mail2.viabit.com (mail2.viabit.com [65.246.80.16]) by pigeon.gentoo.org (Postfix) with ESMTP id C5A07E06D6 for ; Fri, 9 Mar 2012 20:09:28 +0000 (UTC) Received: from [10.1.1.204] (unknown [65.213.236.244]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail2.viabit.com (Postfix) with ESMTPSA id 754503837E for ; Fri, 9 Mar 2012 15:09:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=orlitzky.com; s=mail2; t=1331323768; bh=dWgpheegsqZ3vOuNymK1zhVR/cslZ4PXB84XriWXwMU=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xt0MrJ2v71VO1RgGluXTa0Vxwj5G1RZ2aF2QBgqNjmTsRzEdpPHhgaIN8SLvTGumG Dcr+65cuKmU5zrS4YGHTi3fHBECLjR9xGOA9Sz35C7ZgvclcbXYhzj8Qz7H/cH1uST nNBDuwjva2g6Z0X4bVLJNhY3PcX8A6KGzzfsDzOg= Message-ID: <4F5A6378.8050608@orlitzky.com> Date: Fri, 09 Mar 2012 15:09:28 -0500 From: Michael Orlitzky User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120116 Thunderbird/9.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFD: EAPI specification in ebuilds References: <20311.51166.725757.212932@a1i15.kph.uni-mainz.de> <4F57DDB5.3090503@orlitzky.com> <20120308130310.69c3c714@pomiocik.lan> <4F58D6A5.7070804@orlitzky.com> <20120308182844.11201771@pomiocik.lan> <4F58F103.5010503@orlitzky.com> <20120308175345.2c4b72ff@googlemail.com> <4F58FC55.7070005@orlitzky.com> <20120308184820.108fc30c@googlemail.com> <4F592612.6050203@orlitzky.com> <20120309060424.09cdce1e@pomiocik.lan> <4F599692.9050503@orlitzky.com> <20120309172921.281ee5a0@pomiocik.lan> <4F5A368D.2020605@orlitzky.com> <20314.14772.897891.110368@a1i15.kph.uni-mainz.de> <4F5A3E6C.4040900@orlitzky.com> <4F5A4D05.3040704@orlitzky.com> <4F5A5243.9080600@gentoo.org> In-Reply-To: <4F5A5243.9080600@gentoo.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: f2b53fcf-94ee-4dd2-9f6d-d57681ac40ea X-Archives-Hash: c9c7aa15ef0f3c0750a98ec99ae21fd1 On 03/09/12 13:56, Zac Medico wrote: > On 03/09/2012 10:33 AM, Michael Orlitzky wrote: >> On 03/09/12 13:02, James Broadhead wrote: >>> On 9 March 2012 17:31, Michael Orlitzky wrote: >>>> At any rate, I'm now convinced that we all want GLEP 55, but with a >>>> different name. >>> >>> I think that moving the data to the filename is probably a better >>> approach than semi- or repeat parsing, but I prefer preserving the >>> .ebuild extension, and think that eapi should be specified similarly >>> to ebuild revision, as a suffix. for instance: >>> >>> app-foo/bar-1.0.0-r1.ebuild # EAPI0 (or the highest EAPI prior to the >>> new schema) >>> app-foo/bar-1.0.0-r1-e1.ebuild >>> app-foo/bar-1.0.0-r1-e99.ebuild >>> >> >> One of the benefits of GLEP 55 naming is that old package managers won't >> try to parse them. So, for example, if we put new features in, >> >> app-foo/bar-1.0.0.ebuild-5 >> >> portage from 2003 won't try to source it. > > Every software product has an end of life. I think if a system hasn't > been updated in the last 2 years or so, then it's fair to assume that it > will never be updated. So, all relevant versions of portage should > simply show a warning message if the encounter an ebuild name such as > "app-foo/bar-1.0.0-r1-e99.ebuild". I was just repeating your point against the eapi function =) And there is a non-zero benefit to it, I've had to rescue systems that haven't seen an update in years. The best reason I can think of for using ebuild-EAPI is simply semantic. The basename of the ebuild refers to the package, the extension decides what interprets it. That is at least consistent with every other file extension.