From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RgHv4-0007yb-99 for garchives@archives.gentoo.org; Thu, 29 Dec 2011 15:29:26 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 64E0221C0AF; Thu, 29 Dec 2011 15:29:14 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7F47F21C069 for ; Thu, 29 Dec 2011 15:28:40 +0000 (UTC) Received: from epia.jer-c2.orkz.net (D4B2706A.static.ziggozakelijk.nl [212.178.112.106]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jer) by smtp.gentoo.org (Postfix) with ESMTPSA id 297A91B401F for ; Thu, 29 Dec 2011 15:28:38 +0000 (UTC) Date: Thu, 29 Dec 2011 16:28:31 +0100 From: Jeroen Roovers To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Versioning of eclasses and possibly functions inside ebuilds Message-ID: <20111229162831.6575916c@epia.jer-c2.orkz.net> In-Reply-To: <20111229033601.GA18706@localhost> References: <4EFB6C24.1070307@gentoo.org> <20111229033601.GA18706@localhost> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.5; i686-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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: e628fd67-2dd1-4233-b3a5-b97ff1fa9c9b X-Archives-Hash: da555da8ee216c64c0d235dc058b7d01 On Wed, 28 Dec 2011 19:36:01 -0800 Brian Harring wrote: > People have problems as is dealing w/ eclasses changing and their > dependencies in external repositories not being updated; this > complicates that issue and introduces the same potential into > gentoo-x86 itself. That's not beneficial. I agree with nearly all of that: introducing changes to an eclass usually means going through the whole tree and fixing what breaks. That's a lot more easy to fix than adding more layers of indirection based on a variable's value and adjusting the value according to the time the ebuild was written versus when the eclass was changed. > Thing to keep in mind beyond the potential for confusion the > proposals entail were they implemented, is the implementation > itself. Timeslices? python eclass api versions (when people have > problems figuring out the existing, *singular* version)? These > things aren't going to be simple which means more than likely, > they're going to break, and more than likely it's going to be a PITA > to maintain it. Last time I took tranquilisers and set myself up to read python.eclass, I found that it still doesn't break at 80 characters. Apparently even that can't be fixed in a timely fashion. Assing even more layers of mystification like: if [[ PYTHON_ECLASS_API = 2 ]]; then python_pkg_setup() { or even: python_pkg_setup() { if [[ PYTHON_ECLASS_API = 2 ]]; then would be insane, in my opinion. Also, from the perspective of an ebuild writer, setting PYTHON_ECLASS_API=2 inherit python would be meaningless lacking a very clear description of what the number 2 means. jer