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 1Lc56b-0004Wm-Rp for garchives@archives.gentoo.org; Tue, 24 Feb 2009 21:46:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EEBD2E00FD; Tue, 24 Feb 2009 21:46:17 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id CE534E00FD for ; Tue, 24 Feb 2009 21:46:17 +0000 (UTC) Received: from [192.168.0.9] (unknown [151.57.3.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id B6D5E648C4 for ; Tue, 24 Feb 2009 21:46:16 +0000 (UTC) Message-ID: <49A46AA9.9050805@gentoo.org> Date: Tue, 24 Feb 2009 22:46:17 +0100 From: Luca Barbato User-Agent: Thunderbird 2.0.0.18 (X11/20081205) 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] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) References: <1234257125.18160.2016.camel@localhost> <1234450419.20950.2.camel@localhost> <20090212160045.GB3642@comet> <20090212161644.GD3642@comet> <20090212162103.256b003f@snowcone> <20090212171055.GA3652@comet> <20090212172109.778fb268@snowcone> <20090212173743.GD3652@comet> <20090212180350.0d9a9df5@snowcone> <1235037961.13198.779.camel@localhost> <20090219125124.33eaa66c@snowcone> <1235077892.13198.1923.camel@localhost> <20090222171658.278ae167@halo.dirtyepic.sk.ca> <49A1E1CB.1000806@gentoo.org> <20090222234800.29d64b8d@snowcone> <49A206A7.3050604@gentoo.org> <49A39CE7.4010201@gentoo.org> <49A3AAA1.6080207@gentoo.org> <49A3B947.2020907@gentoo.org> <49A3D0F6.6080307@gentoo.org> <49A41656.7020100@gentoo.org> <20090224155654.602f6c88@snowcone> <49A455BD.900@gentoo.org> <20090224202525.01016056@snowcone> In-Reply-To: <20090224202525.01016056@snowcone> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 104b4a4b-3f1b-468b-988e-d4c2c5a94ce3 X-Archives-Hash: 4aa506ebc5d2500137f43344abd2b7d4 Ciaran McCreesh wrote: > On Tue, 24 Feb 2009 15:17:01 -0500 > Richard Freeman wrote: >> Why? Just parse the EAPI out of the file before you interpret the >> version and name from the filename. Indeed - you could have a future >> EAPI remove the name and version from the filename entirely. If a >> package manager doesn't understand the EAPI in a file it shouldn't do >> anything at all with it. > > Then you get into the mess of deciding what is or is not an ebuild... > Currently it's well defined; if you start making the package manager > look inside files things get very confusing... an ebuild is something ending with .ebuild ... > It means opening a file that would otherwise not be opened at all. And > if the EAPI is in the file, you have to fish inside that file to pull > it out before you can work out whether the cache entry that might > contain the EAPI already is valid. Keeping in mind that: - if the cache is present you won't do it (so normal users aren't touched) - you just need a way to upgrade portage and nothing else. You: - have to open them on regen, no matter what (you are adding it to portage) - the cache entry has already the eapi value so there it is. >>> ..and it means we can't make arbitrary format changes. >> Well, you would need to preserve the EAPI in the header, but other >> than that you could actually turn an ebuild into an otherwise >> completely binary file, or whatever. Just how much more flexibility >> than that is needed? > > I remember hearing that years ago, except it was "well you can't change > global scope behaviour for EAPIs, but just how much more flexibility > than that is needed?". Given that the fixed header gives you ALL the flexibility. You may give provision to consider the next bytes as any kind of serialization... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero