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 1M5Mnd-0002bj-R1 for garchives@archives.gentoo.org; Sat, 16 May 2009 16:31:50 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7362FE0559; Sat, 16 May 2009 16:31:39 +0000 (UTC) Received: from eric.schwarzvogel.de (eric.schwarzvogel.de [194.97.4.250]) by pigeon.gentoo.org (Postfix) with ESMTP id 3E45AE0559 for ; Sat, 16 May 2009 16:31:39 +0000 (UTC) Received: from klausman by eric.schwarzvogel.de with local (Exim 4.69) (envelope-from ) id 1M5MnS-0003Vv-Mu for gentoo-dev@lists.gentoo.org; Sat, 16 May 2009 18:31:38 +0200 Date: Sat, 16 May 2009 18:31:38 +0200 From: Tobias Klausmann To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] The fallacies of GLEP55 Message-ID: <20090516163138.GA12276@eric.schwarzvogel.de> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20090516092710.GA3221@eric.schwarzvogel.de> <20090516151216.15efc792@snowmobile> <20090516153224.GA4964@eric.schwarzvogel.de> <20090516163421.32935cbc@snowmobile> <20090516154332.GA6646@eric.schwarzvogel.de> <20090516164903.261df865@snowmobile> <20090516155500.GA8506@eric.schwarzvogel.de> <20090516165752.7d0b9fdc@snowmobile> <20090516161558.GA9841@eric.schwarzvogel.de> <20090516171959.6934290c@snowmobile> 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-Disposition: inline In-Reply-To: <20090516171959.6934290c@snowmobile> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: Tobias Klausmann X-Archives-Salt: 1708519f-6571-4842-a853-9d494c3b7970 X-Archives-Hash: 10885dbe1fc9ce0fadbc09a19f46d97f Hi! On Sat, 16 May 2009, Ciaran McCreesh wrote: > > So we're not talking about .ebuild-2 for EAPI=2, .ebuild-3 for > > EAPI=3 etc? That would just be silly and it was the first idea I > > got when I saw the proposal. > > Yes, yes we are. That's just one change, from a static string to a > pattern for a string. > > Heck, pretend GLEP 55 says .eapi-X.eb instead if it makes you happy. It doesn't. I forsee a non-trivial amount of extra work, breakage and pain with a moving extension. And not anywhere near enough benefit in exchange for it. > > Aside from that, one idea that came to me recently was to specify > > per tree what kind of files (version-format-wise, EAPI > > elsewhere[0]) a PM has to expect. Tree distributors (Gentoo > > itself, other similar distros, overlays... ) would be Providing > > that information along a similar route as profiles/repo_name. > > This would also reduce the amount of mixing and matching version > > formats (something undesirable, if you ask me). It would also > > make it easier to take a look at historical (snapshots of) > > repositories. > > It also means an end to nice incremental updates. I think wanting incremental updates for version specs is a dream we should abandon. The ordering issues avoided by doing so would justify it alone, if you ask me. Yes, that means having a flag day for every repository. But since I figure the new spec will be a superset of the old spec, that could be automated. As for EAPI, I feel we agree that it could live inside the file itself under this scheme. My point is this: from experience I suspect having a hard change once and having easy progress on either side of it is preferable to having mid-range complications all the time. > Well, I strongly doubt that anyone's already thought of all the useful > changes we might want to make in the future, so I don't think proposing > a solution that assumes that they have is a good idea. I think it's a river we should think about once we reach it. > Otherwise, in another year or two we'll just be back to "well we need > to change extensions again, but let's just do it as a second one-off > thing". My experience tells me that with proper preparation of *this* change, that can be pushed past the "in the next ten years" mark. And that is close enough to "indefinitely" for me. Regards, Tobias -- Found on a small utility knife in MIT's lab supply: "Caution. Blade is sharp. Keep out of children."