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 1LbWKH-0005m5-Gy for garchives@archives.gentoo.org; Mon, 23 Feb 2009 08:38:10 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CB8DDE033A; Mon, 23 Feb 2009 08:38:08 +0000 (UTC) Received: from smtp.tmcs.ch (113.245.131.213.static.inetbone.net [213.131.245.113]) by pigeon.gentoo.org (Postfix) with ESMTP id A582DE033A; Mon, 23 Feb 2009 08:38:08 +0000 (UTC) Received: from [192.168.168.195] (unknown [212.126.163.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.tmcs.ch (Postfix) with ESMTPSA id 547A3169CB07; Mon, 23 Feb 2009 09:38:07 +0100 (CET) Subject: Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009) From: Tiziano =?ISO-8859-1?Q?M=FCller?= To: Luca Barbato Cc: Ciaran McCreesh , gentoo-council@lists.gentoo.org, gentoo-dev@lists.gentoo.org In-Reply-To: <49A206A7.3050604@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> Content-Type: text/plain Organization: Gentoo Date: Mon, 23 Feb 2009 09:38:06 +0100 Message-Id: <1235378286.31617.6.camel@neuromancer.neuronics-tp.ch> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-council@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 Content-Transfer-Encoding: 7bit X-Archives-Salt: a1f3346a-86aa-46cf-a289-c2a1adb35832 X-Archives-Hash: 4aa86329382912d1f7e347a63bb05885 > What is proposed in glep-55 seems to aim to solve both issues at the > same time (it isn't stated) by switching file extension every time the > eapi is changed. This is slightly against the principle of the least > surprise and apparently is disliked by enough people to lead the > situation to be discussed in the council. > 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.)