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 28D15138247 for ; 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 ; 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 ; 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 ; 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 ; Fri, 15 Nov 2013 11:09:04 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) 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 ; 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 ; 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: References: <20131113151012.04145837@gentoo.org> <5283948F.1000409@gentoo.org> <52841023.9010208@gentoo.org> <20131114061328.09136f6f@gentoo.org> <21125.51627.48994.939938@a1i15.kph.uni-mainz.de> 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 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