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 1LbbnG-0003lb-UQ for garchives@archives.gentoo.org; Mon, 23 Feb 2009 14:28:27 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4BC85E0460; Mon, 23 Feb 2009 14:28:23 +0000 (UTC) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by pigeon.gentoo.org (Postfix) with ESMTP id 2C482E0460 for ; Mon, 23 Feb 2009 14:28:23 +0000 (UTC) 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 <0KFI005YCW6VT7NW@vms173009.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Mon, 23 Feb 2009 08:28:12 -0600 (CST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gw.thefreemanclan.net (Postfix) with ESMTP id 7D6C41759AE4 for ; Mon, 23 Feb 2009 09:28:06 -0500 (EST) Message-id: <49A2B276.1000109@gentoo.org> Date: Mon, 23 Feb 2009 09:28:06 -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] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) References: <1234257125.18160.2016.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> <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> <49A26B84.7040006@gentoo.org> <1235383347.12908.0.camel@neuromancer.neuronics-tp.ch> In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Archives-Salt: 270c3199-890a-4959-82d9-ac6675c2b3a2 X-Archives-Hash: 7e668b477c02d8d3fce361ec7fb3b9ee Douglas Anderson wrote: > No one wants to be working with ebuild-29 or something like that in a > few years and trying to figure out which feature came in which EAPI. > Instead of bumping EAPI for each little change, save them up and bump > no more than once a year or less, each bump bringing in some major new > feature. I got the impression that if anything there is a desire to allow EAPIs to change more offen, and not less. And these changes could become more dramatic. I'm not sure this is actually a bad thing (within reason - we do need to have clear specifications for anything that hits production so that we don't have a package manager mess). Also - keep in mind that EAPIs do not need to be numbers and are not ordered. You could have ebuild-i_am_a_furry_monkey or ebuild-. Sure - hopefully the names will be more sensible and somewhat uniform, but we're not necessarily just talking about adding a number to the extension. I still don't see why we need to be encoding metadata in filenames. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. This seems to me to be a solved problem. You put a header in a file that tells you how to read the file. Headers are split into fields and if a program doesn't know what to do with a field it ignores it (or if the header so instructs it doesn't even try to parse the file). This should be easy to do and keep the file bash-compatible. Just stick a comment line close to the top of the file and put whatever you want on it. You could also stick something in metadata.xml (although this makes working with ebuilds outside of a repository more difficult). You run the file through an algorithm to find out what the EAPI is, and then source it if appropriate. Sure, if you make some major change analogous to switching from the .rpm to the .deb package format then maybe an extension change would make sense. But, why expose the inner workings of the package file format to the filesystem?