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 51CB1198005 for ; Wed, 27 Feb 2013 20:30:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B2224E073E; Wed, 27 Feb 2013 20:30:22 +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 B3259E072E for ; Wed, 27 Feb 2013 20:30:21 +0000 (UTC) Received: from [192.168.1.33] (157.Red-2-137-34.dynamicIP.rima-tde.net [2.137.34.157]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pacho) by smtp.gentoo.org (Postfix) with ESMTPSA id 2D0B733DD8C for ; Wed, 27 Feb 2013 20:30:19 +0000 (UTC) Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog From: Pacho Ramos To: gentoo-dev@lists.gentoo.org In-Reply-To: <20130227185824.08f0d035@portable> References: <20130225222029.D84D12171D@flycatcher.gentoo.org> <512E3E06.8010205@gentoo.org> <20130227185824.08f0d035@portable> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-WyxOw42Rg+ZlaH+WElJc" Date: Wed, 27 Feb 2013 21:30:16 +0100 Message-ID: <1361997016.1929.13.camel@belkin4> 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 X-Mailer: Evolution 2.32.3 X-Archives-Salt: 957765d8-3640-48fa-9ef4-9d9988961031 X-Archives-Hash: 422168fe5d19999e4d17549b30332a7b --=-WyxOw42Rg+ZlaH+WElJc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable El mi=C3=A9, 27-02-2013 a las 18:58 +0100, Alexis Ballier escribi=C3=B3: > On Wed, 27 Feb 2013 18:10:30 +0100 > hasufell wrote: >=20 > > I don't want to start another useless rant here, because I perfectly > > understand the issue with ABI specific headers. > >=20 > > 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 >=20 > agreed with that >=20 > > 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. >=20 > except there _has_ been a discussion: > http://article.gmane.org/gmane.linux.gentoo.devel/80330 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Alexis. >=20 >=20 Personally, I second this Alexis appreciations, I also highly appreciate how Michal is working on getting things done and I doubt he broke the tree on purpose (he has contacted me multiple times to ensure wouldn't be collisions in transition period with emul packages, then, I doubt we can blame on him saying he doesn't discuss things enough). He committed a broken package? Yes, but also masked it soon enough and is working on fixing the problem. --=-WyxOw42Rg+ZlaH+WElJc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlEubNgACgkQCaWpQKGI+9Tj9wCeK99YG9VgHHSiYw6zYbOU2lKH UmIAnjGJr9j2df+1wwluUkkjtfP794H0 =MEJe -----END PGP SIGNATURE----- --=-WyxOw42Rg+ZlaH+WElJc--