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 1Lc12O-0001uZ-2v for garchives@archives.gentoo.org; Tue, 24 Feb 2009 17:25:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0D2DEE058A; Tue, 24 Feb 2009 17:25:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D9585E058A for ; Tue, 24 Feb 2009 17:25:42 +0000 (UTC) Received: from vrm378-02.vrm378.am.mot.com (unknown [144.190.95.61]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id CC3CA64E36 for ; Tue, 24 Feb 2009 17:25:41 +0000 (UTC) Date: Tue, 24 Feb 2009 12:25:27 -0500 From: Jim Ramsay 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: <20090224122527.1e800f30@vrm378-02.vrm378.am.mot.com> In-Reply-To: <20090224155654.602f6c88@snowcone> 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> 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_/V=xLTZC7WI8lSlPsCq3LW6H"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: 7b0e001d-7af2-45bf-b8ab-1da0f37cc670 X-Archives-Hash: 4d059d9b6e27c889069aaea483674200 --Sig_/V=xLTZC7WI8lSlPsCq3LW6H Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ciaran McCreesh wrote: > 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. >=20 > ...and it means we can't change name or version rules. >=20 > ...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 > ...and it means we can't make arbitrary format changes. Those would all land in the category of "backwards compatibility" mentioned below, as they would all break current sourcing rules. > > 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. >=20 > 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 I would think that this is a very small cost, and the benefit would be (I hope) that more people would agree on the solution and then we can go forward. Is that not a valid consideration? --=20 Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim) --Sig_/V=xLTZC7WI8lSlPsCq3LW6H Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmkLZIACgkQelWXok6VKui72gCg3m1iUsBLOTC9ODEDh4Y2nStG qfcAoKKEwruPscPdmGplKQtCbWGiKEjR =4WAb -----END PGP SIGNATURE----- --Sig_/V=xLTZC7WI8lSlPsCq3LW6H--