From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-63575-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 28D15138247
for <garchives@archives.gentoo.org>; Fri, 15 Nov 2013 11:09:24 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 24A41E0B75;
Fri, 15 Nov 2013 11:09:17 +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 29416E0B5A
for <gentoo-dev@lists.gentoo.org>; Fri, 15 Nov 2013 11:09:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp.gentoo.org (Postfix) with ESMTP id 37D0333F229
for <gentoo-dev@lists.gentoo.org>; Fri, 15 Nov 2013 11:09:15 +0000 (UTC)
X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org
X-Spam-Flag: NO
X-Spam-Score: -1.232
X-Spam-Level:
X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5.5
tests=[AWL=-1.229, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1])
by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id AkEhfXjKGfcs for <gentoo-dev@lists.gentoo.org>;
Fri, 15 Nov 2013 11:09:06 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
(using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.gentoo.org (Postfix) with ESMTPS id 13F7333F24E
for <gentoo-dev@gentoo.org>; Fri, 15 Nov 2013 11:09:04 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
id 1VhHGl-0007qa-Jp
for gentoo-dev@gentoo.org; Fri, 15 Nov 2013 12:08:59 +0100
Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Fri, 15 Nov 2013 12:08:59 +0100
Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@gentoo.org>; Fri, 15 Nov 2013 12:08:59 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
From: Duncan <1i5t5.duncan@cox.net>
Subject: [gentoo-dev] Re: Please consider removing use.stable.mask and
package.use.stable.mask
Date: Fri, 15 Nov 2013 11:08:38 +0000 (UTC)
Message-ID: <pan$d0f5e$e0d59542$c111e5c2$c6c16f1e@cox.net>
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>
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
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net
User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 6e6fd84
/usr/src/portage/src/egit-src/pan2)
X-Archives-Salt: 3738f4d2-2e37-444a-9aa8-c538a1a69b2d
X-Archives-Hash: dd9d422d83d113e77cea2fb17cc94bfe
Ulrich Mueller posted on Fri, 15 Nov 2013 08:13:47 +0100 as excerpted:
>>>>>> 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.
Indeed. From amd64's gentoo roots the gentoo/amd64 people considered
emul-* a sort-of-embarrassing workaround for a distro such as gentoo,
where for many the biggest /point/ is building from sources in ordered to
enable more user-level customization. Basically it was and remains a
case of saying "Umm... we believe in building from source, except don't
look too closely because in some cases we don't."
If people are willing to accept emul-* because it's "easier", why bother
with gentoo at all, because binary distros that make all compile-time
choices for the user are even /easier/?
So indeed, emul-* is a workaround, and quite a hacked up one for a distro
such as gentoo at that, NOT a solution.
However, I'd replace it as a solution with the (32-bit) chroot solution,
which I use here along with no-multilib for my main amd64 system, except
that I extended the chroot to build the full image (including kernel,
system daemons, grub, etc, that wouldn't need built on a simple 32-bit
chroot) so as to be able to transfer it first via USB thumbdrive and
eventually via SSH to my 32-bit netbook, which boots from it. (I could
thus make the 32-bit image on my main machine bootable as well, with
trivial effort, letting me dual-boot it, but I've had no reason to do so.)
The 32-bit chroot solution is indeed a full gentoo-level solution,
already documented, requiring no changes to the tree or to PMs, since it
uses the existing x86 arch profiles just as they come.
So:
1: emul-* packages[1]
2: multilib-portage
3: multilib.eclass
4: chroot[2]
[1] hacked up workaround, not a proper gentoo level solution.
[2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or either
one for x86-32, or some other combination for other archs.
> 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?
If the perspective is that of a "plain" no-multilib user (even one like
me using the 32-bit chroot solution), or even a standard multilib user
satisfied with the emul-* workaround, then option 3 is very intrusive
indeed, since it has already triggered quite a few package updates with
the only purpose being introduction of a feature these users aren't
particularly interested in. To these folks, options 2 and 4 are
preferred, since for the most part the only folks affected are those who
will actually be using the feature.
Indeed, while option 2 has required some mostly trivial patches and I
think a whole EAPI, option 4 requires none of that, operating with the
existing tree just as it is. It'd be a rare bug indeed that affected a
chroot solution but didn't affect other users of the target arch,
especially since gentoo's installation model already involves chroots, so
bugs involving chroots in @system at least, by /definition/ involve the
affected arch, and should be caught and worked out by releng as a result.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman