From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-63580-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id 20901138247
	for <garchives@archives.gentoo.org>; Fri, 15 Nov 2013 14:27:31 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 48CD7E0A6C;
	Fri, 15 Nov 2013 14:27:24 +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 53A66E0A44
	for <gentoo-dev@lists.gentoo.org>; Fri, 15 Nov 2013 14:27:23 +0000 (UTC)
Received: from [192.168.1.160] (CPE002401f30b73-CM001cea3ddad8.cpe.net.cable.rogers.com [99.224.181.112])
	(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: axs)
	by smtp.gentoo.org (Postfix) with ESMTPSA id 31C8933F198
	for <gentoo-dev@lists.gentoo.org>; Fri, 15 Nov 2013 14:27:22 +0000 (UTC)
Message-ID: <52862F38.8010707@gentoo.org>
Date: Fri, 15 Nov 2013 09:27:04 -0500
From: Ian Stakenvicius <axs@gentoo.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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] Please consider removing use.stable.mask and package.use.stable.mask
References: <slrnl86l1s.j7e.vaeth@lounge.imp.fu-berlin.de>	<20131113151012.04145837@gentoo.org>	<5283948F.1000409@gentoo.org>	<52841023.9010208@gentoo.org>	<20131114061328.09136f6f@gentoo.org>	<CAB9SyzTB3Nqd8bsFpRoFvgU-RHuB4W7CG76La6qu-WQ4O7kS0g@mail.gmail.com>	<CAGfcS_kJM+0_BykpaXCcxRXi9Tw2jz=jx3Khsa6Ou_3uX6mUOA@mail.gmail.com>	<CAB9SyzSqd1fW=v1NOjetHKCX0+WxHNgWreC5JqUsEZj4RaFL3A@mail.gmail.com>	<CAGfcS_nrGjs4hw0udBFeCbHyNR4=x6GK_YNuTzNtm1gL+XKayQ@mail.gmail.com>	<CAB9SyzRyjeEfWLWLw82W+aZE1gDowgnbaKwRurMRR7V2kx0ABA@mail.gmail.com>	<CAGfcS_ka=m0EjoSdTX2QgF4oN30zpUEm+C=5nTZxT-jBfzD4rQ@mail.gmail.com>	<CAB9SyzRX38zFT8ZKV+kNNfc2PnHqqisXSDUUbNvTVCQvdzDdrg@mail.gmail.com> <21125.51627.48994.939938@a1i15.kph.uni-mainz.de>
In-Reply-To: <21125.51627.48994.939938@a1i15.kph.uni-mainz.de>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Archives-Salt: 7bbd219f-7c31-4d67-b27c-03599fd1a5cd
X-Archives-Hash: 78876400fff9078e61e969957500245d

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 15/11/13 02:13 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 15 Nov 2013, Ben de Groot wrote:
> 
>> As I see it now, with respect to multilib, we have three
>> competing solutions, but not a clear direction which way we want
>> to go as a distro:
> 
>> 1: emul-* packages 2: multilib-portage 3: multilib.eclass
> 
>> I would like to vote for option 1, as it is the least intrusive
>> and does what we need. If it is really felt we need a more
>> complete solution, then my vote would be for 2, since 3 is too
>> intrusive and more likely to break or complicate stuff for normal
>> users.
> 
> Option 1 is not a solution, but a workaround. It has served us, but
> IMHO its replacement is overdue. Just to give an example, stable
> emul-linux-x86-xlibs suffers from several security issues (bug
> 471098, A1/critical severity) since half a year.
> 
> Besides, distributing pre-compiled binary packages seems very 
> un-Gentoo-ish.
> 
> Not sure why you think that option 3 is more intrusive than option
> 2. What can be more intrusive than requiring a modified package
> manager?

I concurr -- option #1 has existed for some time but it's entirely a
workaround rather than a solution.

Option 2 and Option 3, though, I don't see as having to be a competing
system -- to me they provide for different goals (most of which
overlap, but still).

Multilib-portage provides the ability to build an entire userland in
as many ABIs as can be supported -- bins, libs, the whole deal; no
matter if the in-tree ebuilds have an alt-ABI specification or not.

The multilib eclasses allow any ebuild that needs to, to depend on a
non-native-ABI library and forces any package manager to work it out
via use flags.

#3 works for everyone in a more limited scope than #2 (just libs,
generally with the goal of only including the few libs the in-tree
consumers actually need).  #2 provides users that want it with a
specific PM to manage their system, as alternative to the other PMs
out there.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlKGLzgACgkQ2ugaI38ACPCrkgD+JNG1iF/oGh/5gXtqhTXlhHGL
A4tM6dbfZxmt793CTGwA+wercYN3gwb10GHyxs0bUMkime+cWDFpPphjPHU9BAtn
=BPc1
-----END PGP SIGNATURE-----