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 11A85198005 for ; Wed, 27 Feb 2013 17:10:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 95CDFE0774; Wed, 27 Feb 2013 17:10:36 +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 BA13DE074B for ; Wed, 27 Feb 2013 17:10:35 +0000 (UTC) Received: from [192.168.4.5] (blfd-5d823cfa.pool.mediaWays.net [93.130.60.250]) (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 4692C33DEAE; Wed, 27 Feb 2013 17:10:34 +0000 (UTC) Message-ID: <512E3E06.8010205@gentoo.org> Date: Wed, 27 Feb 2013 18:10:30 +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, mgorny@gentoo.org Subject: [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> In-Reply-To: <20130225222029.D84D12171D@flycatcher.gentoo.org> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 948e9a16-8ee4-4eec-a537-ea145fcab6f2 X-Archives-Hash: 0e44328c3412e3afe58a9d4c8e810672 I don't want to start another useless rant here, because I perfectly understand the issue with ABI specific headers. The problem is: a) if you break a provider on purpose, then you should feel somehow responsible for the consumers and not just dump testing and fixing on your fellow devs b) just test such things in an overlay first and see it explode, then think about it again and ask on dev-ML if other people find it even WORTH the hassle The other thing is: We still have the conflict with eclass-solution vs PM-solution (multilib-portage) and I propose not to convert ANYTHING else until that conflict is solved, even if it means a council vote (that's what I actually think makes sense here). I understand both sides and somehow find it appealing to have a quicker solution, but since this could damage years of work on a portage fork I think we should slow down here.