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 1Lc3qU-0008S1-2f for garchives@archives.gentoo.org; Tue, 24 Feb 2009 20:25:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 45D57E0559; Tue, 24 Feb 2009 20:25:36 +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 D3B46E0559 for ; Tue, 24 Feb 2009 20:25:35 +0000 (UTC) Received: by bwz1 with SMTP id 1so6006788bwz.10 for ; Tue, 24 Feb 2009 12:25:35 -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=JDxoVUivzyjv9hXWS2a5UGVg7PZx0bcyputsaq9QRCY=; b=j+/TlcEnAd3CM5ouXzbe0Xb0R7BASRzkjz7L5I+oNFv1AqxIvtj5V83EJwHwKhtDSs 2mG14VeW1qNgA9JzALKaPzH60RBXzBhRU5smO1H80byThVmiFbysgOBMU7JcKiYlzv12 19DnAJWSVhC6jqxK907cPesLFV2x6jVSJO/EI= 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=ND7w1guTZfIu9P2wC2sVJirMHn//1I+PtIenFPi9XsA0hfrNYoZ3i70pfCu5bV3hik jM/oty0dgV9DgNCBSsbo8sLRQEhIWX9HI2PlxaWBhwiwAPhz1vOiZDDm0fZ4BNCp03+m LRAXLNj0uPPlDZ+HrtvlBQACGeGFu7Kg7QiF4= Received: by 10.103.226.20 with SMTP id d20mr16746mur.8.1235507134609; Tue, 24 Feb 2009 12:25:34 -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 r38sm9513539ugc.9.2009.02.24.12.25.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 12:25:34 -0800 (PST) Date: Tue, 24 Feb 2009 20:25:25 +0000 From: Ciaran McCreesh 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) Message-ID: <20090224202525.01016056@snowcone> In-Reply-To: <49A455BD.900@gentoo.org> 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> <49A455BD.900@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_/JS1cGsLD8F7BreN5Qq4NgI="; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 34956f22-6c73-42f5-b3b3-84033060ec12 X-Archives-Hash: 180e5caf585b8a9f5931af1570399013 --Sig_/JS1cGsLD8F7BreN5Qq4NgI= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 24 Feb 2009 15:17:01 -0500 Richard Freeman wrote: > Why? Just parse the EAPI out of the file before you interpret the=20 > version and name from the filename. Indeed - you could have a future=20 > EAPI remove the name and version from the filename entirely. If a=20 > package manager doesn't understand the EAPI in a file it shouldn't do=20 > anything at all with it. Then you get into the mess of deciding what is or is not an ebuild... Currently it's well defined; if you start making the package manager look inside files things get very confusing... > > ..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. >=20 > 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? It means opening a file that would otherwise not be opened at all. And if the EAPI is in the file, you have to fish inside that file to pull it out before you can work out whether the cache entry that might contain the EAPI already is valid. (We don't have to do this currently because inherit hasn't changed behaviour at all.) > > ..and it means we can't make arbitrary format changes. >=20 > 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? I remember hearing that years ago, except it was "well you can't change global scope behaviour for EAPIs, but just how much more flexibility than that is needed?". --=20 Ciaran McCreesh --Sig_/JS1cGsLD8F7BreN5Qq4NgI= Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmkV7kACgkQ96zL6DUtXhHmyACfQ0qdCqlQd3WlzkfDxR6VqPiv bEwAoK5ZiSPSM3rJPi8ZMcSO72b+V3Je =mcSh -----END PGP SIGNATURE----- --Sig_/JS1cGsLD8F7BreN5Qq4NgI=--