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 1Lbbup-0004Uw-Ko for garchives@archives.gentoo.org; Mon, 23 Feb 2009 14:36:15 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E60DE016D; Mon, 23 Feb 2009 14:36:13 +0000 (UTC) Received: from mail-bw0-f157.google.com (mail-bw0-f157.google.com [209.85.218.157]) by pigeon.gentoo.org (Postfix) with ESMTP id D105BE0146 for ; Mon, 23 Feb 2009 14:36:12 +0000 (UTC) Received: by bwz1 with SMTP id 1so4740190bwz.10 for ; Mon, 23 Feb 2009 06:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=XqpN437n9oWYDAD1RPBRxu2a+7YOr1TYjSLT/zjoXB0=; b=dsu6P82UrVjBnsu5phHd6icsgagyA0GCHOLPNUzb5OrMo4jjxO/t8IYZPUcCNpb1j5 vrEHpVmft83eDUutW3BU9jBB849ssSbCpR9uWtEdHRER2qPNwZRjiYJHFhBndfZZoGFR mTSCuIx7qK6xBjEog523G8ZH3Bz2itt4ascCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=yACkPym0h2BXH82rfZc7MymhhsGsoJDygojhOnQdQb2fpoiVoZOQquFirkVqWxMOvr kFzrzl782TdJdbolQwV8jd4XTk8Mb1oyWQyfqdITWkYc66eoY1IBSHr9VTXIjntCPuyK 7aa0tqC702c8GY1Zh0CTdR4nz8w4p1IZmLvaU= Received: by 10.103.223.2 with SMTP id a2mr3353999mur.4.1235399771927; Mon, 23 Feb 2009 06:36:11 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id 30sm16049135ugf.45.2009.02.23.06.36.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 06:36:11 -0800 (PST) Date: Mon, 23 Feb 2009 14:36:04 +0000 From: Ciaran McCreesh 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) Message-ID: <20090223143604.6dd2afbc@snowcone> In-Reply-To: <49A2B276.1000109@gentoo.org> 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> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) 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: multipart/signed; boundary="Sig_/Bx_cc5cBcPYqIYlb51lGtCE"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 90bc28ef-6546-4ca9-8710-767bd92dce93 X-Archives-Hash: 3dbaaece6465a06d0e94559872c41fe7 --Sig_/Bx_cc5cBcPYqIYlb51lGtCE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 23 Feb 2009 09:28:06 -0500 Richard Freeman wrote: > 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. But we're still only talking maybe three new EAPIs a year. > Also - keep in mind that EAPIs do not need to be numbers and are not=20 > ordered. You could have ebuild-i_am_a_furry_monkey or=20 > ebuild-.=20 > 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. You're using "developers might do something really stupid" as an argument? By that logic, the current setup sucks since someone might make an EAPI called a'b"c\d , so developers might have to put weird escaping in when specifying EAPI. Also note that kdebuild went with .kdebuild-1, not .ebuild-kdebuild-1. It's no leap to have slightly different extension rules for any project that creates its own non-numerical EAPIs. > I still don't see why we need to be encoding metadata in filenames.=20 Because the metadata has to be known before the file can be used. > 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. Back when Perl 5 and PHP 5 were new, people often used extensions like .php4 and .php5 to tell their webserver how to handle scripts... > This seems to me to be a solved problem. You put a header in a file=20 > 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. That doesn't work with existing packages or existing package managers. > 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? For the same reason versions and package names are already in the filename. --=20 Ciaran McCreesh --Sig_/Bx_cc5cBcPYqIYlb51lGtCE Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmitFcACgkQ96zL6DUtXhHkFACggoqUUTHgrV1gx8qG4ZyiPg1q znEAoNx6W/8Hok7VC51YeyF100n6ZXs2 =d+TH -----END PGP SIGNATURE----- --Sig_/Bx_cc5cBcPYqIYlb51lGtCE--