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 1Lbzwx-0002i7-2Q for garchives@archives.gentoo.org; Tue, 24 Feb 2009 16:16:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2D6FDE03E0; Tue, 24 Feb 2009 16:16:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 101BAE03E0 for ; Tue, 24 Feb 2009 16:16:02 +0000 (UTC) Received: from [67.40.138.82] (crater.wildlava.net [67.40.138.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 7611364CB7 for ; Tue, 24 Feb 2009 16:16:01 +0000 (UTC) Message-ID: <49A41D3F.4010706@gentoo.org> Date: Tue, 24 Feb 2009 09:15:59 -0700 From: Joe Peterson User-Agent: Thunderbird 2.0.0.19 (X11/20090110) 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> <49A2B276.1000109@gentoo.org> In-Reply-To: <49A2B276.1000109@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: d0c28c0a-b96e-4a08-997e-8ef672a75cab X-Archives-Hash: ddbdcfaf0c53f54fbcf7874d697079a3 Richard Freeman wrote: > I still don't see why we need to be encoding metadata in filenames. Correct. GLEP 55 tries to solve a technical implementation issue by exposing meta data in the filename. Extremely bad form/design, IMHO. > 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. All good points. I cannot believe there exists no other way to solve this technical issue other than resorting to such a non-Unix-like idea. Obviously all of the software packages cited above endeavor to avoid such nastiness. I do not understand why anyone is willing to accept putting version info in the filename/extension. It is inelegant and, frankly, very ugly. I have written more in the past on why I think it is a terrible idea, so I won't repeat it here. Suffice to say, if something like GLEP 55 is implemented, I will lose a lot of faith in Gentoo's design, so much so that I will likely join the ranks of those who abandon it, not only as a dev, but also as a user. > 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? +100 -Joe