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 1Lbzf3-0006pF-AR for garchives@archives.gentoo.org; Tue, 24 Feb 2009 15:57:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 20E30E03E1; Tue, 24 Feb 2009 15:57:02 +0000 (UTC) Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.145]) by pigeon.gentoo.org (Postfix) with ESMTP id EBEF4E03E1 for ; Tue, 24 Feb 2009 15:57:01 +0000 (UTC) Received: by qw-out-1920.google.com with SMTP id 9so984521qwj.10 for ; Tue, 24 Feb 2009 07:57:01 -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=MT7g1x9+ZjD8alSDm2cgT8i8wjR+eSwUpeuwR3QtDRg=; b=r4m42ZXhp8w8SWbK2sNmE1BfGqAT1hP76tSHshOPCa94Mv0ox0pLPk/eNLjDbrKcO3 yNgekGJROTcxLvNQ3cI8xVHLVPOWZ1DTwNUme6hUo5DEDf9RYniR2N5kWbRLc8SIF0tH osvIbnr8/T3Bs+7LiyIowaif9NrqsWY/+C6E4= 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=vr3bAcNo+oTCkqI3STkYQR8+qD9p+FcX9MWmqsyYWJa+UlDNZE/8kzUg3c5akvdsYI gMWmzmvAkTIz+kUnyyy8ER6XnfyGGPK3gAfeoBO/hOTtKcSe2vQvHP7LWsh5eWmP7r4y EZKDk/FQHeW69PuqBcCy57K3O+tm7Y6Yh06wg= Received: by 10.224.36.202 with SMTP id u10mr8277547qad.122.1235491021611; Tue, 24 Feb 2009 07:57:01 -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 32sm19319908ugf.19.2009.02.24.07.57.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 07:57:01 -0800 (PST) Date: Tue, 24 Feb 2009 15:56:54 +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: <20090224155654.602f6c88@snowcone> In-Reply-To: <49A41656.7020100@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> 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_/g.Gp_kIEGPEdUYa=IwKIeHz"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: d167a705-a3ca-4ce9-a75d-a3553c0750c9 X-Archives-Hash: 0cccc31301fac0d45a09af27c9c59695 --Sig_/g.Gp_kIEGPEdUYa=IwKIeHz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 24 Feb 2009 10:46:30 -0500 Richard Freeman wrote: > I will certainly concede that putting it inside the ebuild > potentially breaks compatibility with existing package managers. > That is certainly a downside to this approach. However, none of the > other objections that have been raised appear to hold water. ...and it means we can't change name or version rules. ...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. ...and it means we can't make arbitrary format changes. > And if backwards compatibility were a serious issue you could define > a new ".ebuild2" file spec that incorporates the EAPI inside the file > and current package managers would ignore it. Then you're not > changing the file extension every time a new EAPI comes along, and > the need to do so could be handled via future GLEPs. Developers already have to stop and think and consult the conveniently available table of features for EAPIs. By splitting the EAPI concept in two you're doubling the amount of data to be learnt. --=20 Ciaran McCreesh --Sig_/g.Gp_kIEGPEdUYa=IwKIeHz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmkGMkACgkQ96zL6DUtXhFRcQCgtxpPZOuKHqTTChd1S7Oy79QV NY0AnAyNuY03gyY7XrZ+d7Wfa2K32JGu =aVzi -----END PGP SIGNATURE----- --Sig_/g.Gp_kIEGPEdUYa=IwKIeHz--