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 69DCC198005 for ; Wed, 27 Feb 2013 17:58:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 05ED1E08EB; Wed, 27 Feb 2013 17:58:32 +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 25B9FE08DC for ; Wed, 27 Feb 2013 17:58:31 +0000 (UTC) Received: from portable (AMontpellier-651-1-311-23.w92-133.abo.wanadoo.fr [92.133.70.23]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 1358633DD61; Wed, 27 Feb 2013 17:58:28 +0000 (UTC) Date: Wed, 27 Feb 2013 18:58:24 +0100 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Cc: hasufell@gentoo.org, mgorny@gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog Message-ID: <20130227185824.08f0d035@portable> In-Reply-To: <512E3E06.8010205@gentoo.org> References: <20130225222029.D84D12171D@flycatcher.gentoo.org> <512E3E06.8010205@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.16; x86_64-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: 2900eba8-efd5-4560-b952-c1945baefcd7 X-Archives-Hash: eda327849f372926a3a06e2b7647c8fd On Wed, 27 Feb 2013 18:10:30 +0100 hasufell wrote: > 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 agreed with that > 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. except there _has_ been a discussion: http://article.gmane.org/gmane.linux.gentoo.devel/80330 where, at least for me, it appeared that the eclass solution was the right way and portage-multilib had its defects that could not be solved without such an eclass solution. Long story short: portage-multilib does not handle deps needing multilib and deps not needing them. Only packages maintainers know that, you cannot guess it at the PM level. Doing unpack twice, while bearable, is also suboptimal. portage-multilib already disables its multilib support for multilib-enabled packages, thus there is not even a conflict there. The lack of answer on my reply ( http://article.gmane.org/gmane.linux.gentoo.devel/82740 ) made me think that the main portage-multilib developer was agreeing with that. On the other hand, Michal has been doing the work and got things done when portage-multilib has never reached mainline after several years of development. So, while breaking the tree like the freetype case is really bad, please do not use this for killing his efforts, esp. when it is now masked. If you want to start another discussion on the subject, then please make a summary of the previous ones and start it (council will very likely ask you to do it if you want a vote anyway). If you do not want to, then please thank Michal for getting things done and finally giving us a sane multilib support. Alexis.