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 1Lc3iS-00076d-6L for garchives@archives.gentoo.org; Tue, 24 Feb 2009 20:17:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 04650E05E6; Tue, 24 Feb 2009 20:17:18 +0000 (UTC) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by pigeon.gentoo.org (Postfix) with ESMTP id D947BE05E6 for ; Tue, 24 Feb 2009 20:17:17 +0000 (UTC) Received: from gw.thefreemanclan.net ([68.162.77.20]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KFL00H8F70D2481@vms173007.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Tue, 24 Feb 2009 14:17:07 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 4F9A219E2EB3 for ; Tue, 24 Feb 2009 15:17:01 -0500 (EST) Message-id: <49A455BD.900@gentoo.org> Date: Tue, 24 Feb 2009 15:17:01 -0500 From: Richard Freeman User-Agent: Thunderbird 2.0.0.19 (X11/20090104) 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> In-reply-to: <20090224155654.602f6c88@snowcone> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Archives-Salt: 32387186-e6ea-4a70-a554-620a0b5e9bae X-Archives-Hash: d0aff4cbb60f980791f0007681fddc2e Ciaran McCreesh wrote: > > ..and it means we can't change name or version rules. > 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. > ..and it means over doubling the best possible time to work out a > dependency tree in the common case where the metadata cache is valid. > I can see why it takes an extra pass - but does that mean a doubling of time? Couldn't the EAPI be cached as well to reduce disk access? > ..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?