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 1Lbakb-0004ZF-A5 for garchives@archives.gentoo.org; Mon, 23 Feb 2009 13:21:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A53EAE03E9; Mon, 23 Feb 2009 13:21:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7ECF9E03E9; Mon, 23 Feb 2009 13:21:35 +0000 (UTC) Received: from [192.168.0.91] (83-103-77-215.ip.fastwebnet.it [83.103.77.215]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id E1EB5B596E; Mon, 23 Feb 2009 13:21:33 +0000 (UTC) Message-ID: <49A2A2DD.7080706@gentoo.org> Date: Mon, 23 Feb 2009 14:21:33 +0100 From: Luca Barbato User-Agent: Thunderbird 2.0.0.18 (X11/20081205) 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 CC: Ciaran McCreesh , gentoo-council@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> <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> <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> In-Reply-To: <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 1df2746f-3804-458a-afd0-4a4674158bf4 X-Archives-Hash: eb4cdc566ab3eb80701c466ccd0cbb3e Tiziano M=C3=BCller wrote: >> What is proposed in glep-55 seems to aim to solve both issues at the=20 >> same time (it isn't stated) by switching file extension every time the= =20 >> eapi is changed. This is slightly against the principle of the least=20 >> surprise and apparently is disliked by enough people to lead the=20 >> situation to be discussed in the council. >> >=20 > Instead of switching file extension every time the eapi is changed you > could also increment it only when a new EAPI breaks sourcing the ebuild > compared to the requirements of the prior EAPI. > (This way you'd in fact split EAPI into a major- and a minor-version.) Makes you getting to have to do the two stage source again AND you get=20 another non obvious condition "Should I bump the eapi internally or the=20 filename?" The main point again what is proposed in glep-55 is it that isn't=20 invasive and non-transparent to users and developers. As stated in the analysis, the user side is already covered by the fact=20 users use the cache, the developer side would require a two stage=20 sourcing when committing to remain transparent. What we need to balance is if the invasive proposal is simpler than=20 having a two stage sourcing done. lu --=20 Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero