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 969551387FD for ; Wed, 2 Apr 2014 00:08:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3F003E07FE; Wed, 2 Apr 2014 00:08:11 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5C33AE0A7D for ; Wed, 2 Apr 2014 00:08:10 +0000 (UTC) Received: from [192.168.1.111] (unknown [114.91.168.239]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: patrick) by smtp.gentoo.org (Postfix) with ESMTPSA id 278FB33FB8C for ; Wed, 2 Apr 2014 00:08:08 +0000 (UTC) Message-ID: <533B5620.1070105@gentoo.org> Date: Wed, 02 Apr 2014 08:13:20 +0800 From: Patrick Lauer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 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 Subject: Re: [gentoo-dev] Stable masks on multilib packages References: <20140401001617.42fdc3bc@pomiot.lan> <1396360717.20406.12.camel@rook> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 48e581ae-2ebe-4613-b5c0-973b3f7bd991 X-Archives-Hash: 91a8dde6441c32496a98a85c404768b6 On 04/01/2014 10:43 PM, Rich Freeman wrote: > On Tue, Apr 1, 2014 at 9:58 AM, Alexandre Rostovtsev > wrote: >> On Tue, 2014-04-01 at 13:13 +0800, Ben de Groot wrote: >>> >>> In my opinion your multilib approach introduces an unnecessary degree >>> of complexity, which --as has been shown here again-- is prone to >>> breakage. >>> >>> It would be best for our beloved distro to revert all the multilib >>> changes, and try a different approach, or leave this prone-to-breakage >>> implementation to an overlay for the few people who would actually >>> benefit from it. >> >> I am aware of only two solutions to the emul-linux-x86-* problems : >> multilib-portage and multilib-build.eclass. The first requires everybody >> to switch to a new package manager. The second allows us to keep using >> portage, but requires library maintainers to add some simple boilerplate >> to their ebuilds for multilib support. >> >> Do you have yet another alternative in mind? > > ++ > > I'm all for better solutions. I'm not in favor of abandoning > solutions that work moderately well in favor of talking about maybe > coming up with something better sometime down the road. > > The multilib eclass isn't a perfect solution. It will have issues in > concept, design, and implementation. These will come up from time to > time. I don't think it is productive that anytime any of these pop up > that we end up having a discussion about just reverting it entirely. So why do we have this discussion? > By all means work on a competing solution. Get it working and > supported by portage. When the day comes that we want to endorse one > solution or the other as the preferred solution we can have that > discussion. That is hilariously funny. Wow. Now let's just continue to ignore the existing multilib-portage work so we can claim it's irrelevant, while shifting the conditions for accepting it whenever it is convenient, while silently adding the competing method in-tree so it's all decided now anyway ...