From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 35F1E198005 for ; Sat, 2 Mar 2013 15:01:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A3993E0676; Sat, 2 Mar 2013 15:01:51 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C1392E0656 for ; Sat, 2 Mar 2013 15:01:50 +0000 (UTC) Received: from [192.168.4.5] (blfd-4d08f589.pool.mediaWays.net [77.8.245.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 5615233DD06; Sat, 2 Mar 2013 15:01:49 +0000 (UTC) Message-ID: <51321457.7080300@gentoo.org> Date: Sat, 02 Mar 2013 16:01:43 +0100 From: hasufell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130123 Thunderbird/17.0.2 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: mgorny@gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog References: <20130225222029.D84D12171D@flycatcher.gentoo.org> <512E3E06.8010205@gentoo.org> <20130227185824.08f0d035@portable> <512E4D0E.9070700@gentoo.org> <20130227192722.65a55ac5@portable> <512E5916.4050208@gentoo.org> <20130302120838.06fcf599@portable> In-Reply-To: <20130302120838.06fcf599@portable> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 8e444d2c-6e6d-4d9a-9776-35195e87d756 X-Archives-Hash: 335151c6451423422a0fafeed0a87a15 On 03/02/2013 12:08 PM, Alexis Ballier wrote: > >> eclass level: >> pro: >> - easier to maintain (eclasses are generally easy understandable) >> - quicker to fix and to extend >> - solution is NOW available >> con: >> - more likely to break stuff as all eclass based solutions, because >> there are no eclass-APIs and no spec > > if done correctly this should not happen, but that's true the eapi > barrier is not there. > >> - needs much more modification on ebuilds, especially for weird >> build systems > > the eclass you proposed implements more or less the multilib-portage > solution without much changes. if you want to do it cleanly (out of > source build, etc) then yes you need much more changes but also get > something you cannot do from the PM side. > >> - not tree-wide, slow per-package migration > > it is a pro rather than a con for me: do we really want lib32 to be the > 32bits copy of lib64? or do we want here only what actually makes > sense, on a per-package and per-need basis? (see also the tl-latexextra > example above) > IMO we should go on with eclass development. Tommy has already offered to help with that, but would appreciate if we implement a check/switch that will disable all multilib-eclass related magic and allowing multilib-portage to still work tree-wide as it did before we invented these eclasses. I think that's a fair trade. And at least for my eclass I already have implemented a solution, basically doing: if [[ $(multilib_get_enabled_abis) == ${DEFAULT_ABI} ]] ; then DISABLE_MULTILIB="ON" fi which will disable multilib-behavior if only the default abi is set. Alternatively we could simply introduce DISABLE_MULTILIB as an eclass variable which can be set by multilib-portage then. Mgorny still has not replied to this proposition.