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 1Lc7nC-0002u5-Lu for garchives@archives.gentoo.org; Wed, 25 Feb 2009 00:38:30 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A0AD3E06F9; Wed, 25 Feb 2009 00:38:27 +0000 (UTC) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by pigeon.gentoo.org (Postfix) with ESMTP id 815A6E06F9 for ; Wed, 25 Feb 2009 00:38:27 +0000 (UTC) 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=UTF-8; format=flowed Received: from gw.thefreemanclan.net ([68.162.77.20]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KFL00L68J3L35Q8@vms173009.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Tue, 24 Feb 2009 18:38:09 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 64D7E1759D08 for ; Tue, 24 Feb 2009 19:38:08 -0500 (EST) Message-id: <49A492F0.8020402@gentoo.org> Date: Tue, 24 Feb 2009 19:38:08 -0500 From: Richard Freeman User-Agent: Thunderbird 2.0.0.19 (X11/20090104) To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives References: <49A472E3.1010204@gentoo.org> In-reply-to: <49A472E3.1010204@gentoo.org> Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c1960e8f-1be3-48c7-a8e0-6d693fca6361 X-Archives-Hash: bf3aa0199bb521b263b19b4997a0429c Petteri R=C3=A4ty wrote: > 3) EAPI in locked down place in the ebuild > - Allows changing global scope > - EAPI can't be changed in an existing ebuild so the PM can trust > the value in the cache I don't see how this follows. The PM can compare the mtime on the file=20 with the time the cache was updated and refresh if needed. Or we could=20 require users to manually refresh the cache if they modify an ebuild. > - Does not allow changing versioning rules unless version becomes a > normal metadata variable I don't see how this follows. You can put any version in the filename=20 that you like just as with the EAPI in the filename approach. A package=20 manager won't process the filename if it doesn't understand the EAPI.=20 The order of processing for a package manager would be: 1. Scan for files named *.ebuild. 2. Scan the nth line inside to obtain the EAPI. 3. Take further action in accordance with the EAPI - possibly including=20 obtaining the package name/version from the filename, or maybe somewhere=20 else entirely. > * Needs more accesses to cache as now you don't have to load older > versions if the latest is not masked Why wouldn't you cache every version of a package with its EAPI for=20 reference? I don't follow why this needs more cache hits. However,=20 even if you had to hit the cache more often I don't see why a cache=20 lookup would be expensive. Isn't it stored in a sensible format for=20 rapid random access? My preference is obviously for embedding the EAPI inside the file in=20 some manner. My second preference would be for only changing the file=20 extension on rare occasions that are individually approved by the=20 Council when things need to change dramatically, as opposed to any time=20 the EAPI changes.