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 B50F21387FD for ; Tue, 1 Apr 2014 23:33:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B50A0E0A82; Tue, 1 Apr 2014 23:33:01 +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 C374DE0A6D for ; Tue, 1 Apr 2014 23:33:00 +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 AE3AD33FC21 for ; Tue, 1 Apr 2014 23:32:59 +0000 (UTC) Message-ID: <533B4DE2.3070808@gentoo.org> Date: Wed, 02 Apr 2014 07:38:10 +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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 9e5abe48-a749-4b47-badc-bce99b44feac X-Archives-Hash: e620ca74ee1a59b18d47daede4181ea3 On 04/01/2014 01:13 PM, Ben de Groot wrote: > On 1 April 2014 06:16, Michał Górny wrote: >> Hello, all. >> >> The late multilib ppc issues made me re-check our stable masks on >> abi_x86_* flags and, honestly, I'm not sure if we're doing things >> the right way. >> >> That said, I have an alternate idea inspired by the ppc breakage. >> >> Your thoughts? > > In my opinion your multilib approach introduces an unnecessary degree > of complexity, which --as has been shown here again-- is prone to > breakage. And it removes any chance of writing ebuilds - I seriously have no idea how to fix those things now. They are multibuilds, not ebuilds. > > 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. > As a temporary stage they are kinda okish, maybe ... but ... the whole transition strategy has been very very silly and should have been staged in an overlay. I'd even build-test them and file bugs - just don't do this salami tactic of one breakage a day.