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 96895138247 for ; Sun, 17 Nov 2013 16:09:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F1A44E09C6; Sun, 17 Nov 2013 16:09:15 +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 F2E90E09B9 for ; Sun, 17 Nov 2013 16:09:14 +0000 (UTC) Received: from [192.168.4.5] (blfd-4d08fb80.pool.mediaWays.net [77.8.251.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 91C9F33F122 for ; Sun, 17 Nov 2013 16:09:13 +0000 (UTC) Message-ID: <5288EA26.5070204@gentoo.org> Date: Sun, 17 Nov 2013 17:09:10 +0100 From: hasufell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Thunderbird/17.0.9 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] Please consider removing use.stable.mask and package.use.stable.mask References: <20131113151012.04145837@gentoo.org> <5283948F.1000409@gentoo.org> <52841023.9010208@gentoo.org> <20131114061328.09136f6f@gentoo.org> <20131115233934.7142bb04@gentoo.org> <1384590157.1308.13.camel@belkin5> <52874F93.8030501@gentoo.org> In-Reply-To: <52874F93.8030501@gentoo.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 67982cb9-d2d7-43ca-aa76-b4a34d9ec7ca X-Archives-Hash: cb7baa43131b78c0c0fb0e43a377853c -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/16/2013 11:57 AM, Thomas Sachau wrote: > Pacho Ramos schrieb: >> El vie, 15-11-2013 a las 23:39 +0100, Michał Górny escribió: >>> Dnia 2013-11-15, o godz. 14:53:00 Ben de Groot >>> napisał(a): >>> >>>> 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 >> >> This is the current option but has important drawbacks: - Each >> emul set contains a ton of packages, then, when a security issue >> arises in one of them, we need to release a new >> emul-linux-x86-... - It's built from stable tree, it can then >> cause inconsistencies when people run native lib from testing (I >> remember pulseaudio case) - If we would like to really follow >> stabilized packages, we would nearly need to generate a new set >> every week because likely some of the contained packages will be >> stabilized on x86 so often. - As they are a big set of packages, >> people need to install a lot of stuff they don't really need >> >> In summary -> they are completely unflexible, with the problems >> it cause >> >>>> 2: multilib-portage >> >> I think this has been discussed multiple times, if I don't >> misremember, PMS team is not willing to accept it until the >> specification is done... and we are waiting for that for years >> probably because it includes a lot of changes (well, Tommy will >> know much more about this) > > Ever tried to write a formal spec in a foreing language? Creating > multilib-portage was easier then this request.... > > Anyway, the new multilib eclasses had no entrance barrier, so have > been added and effectively everyone is forced to use them. > > Since i dont expect anyone to vote for a different solution in the > future, which would force all multilib related parts to be > rewritten, i stopped my work on the spec part. If anyone wants to > continue that road, i can hand over any pieces i already have. > > Instead i will simply prepare/maintain multilib-portage as a > portage-only package manager based multilib solution, which > requires no changes to ebuilds. This also keeps a choice for users, > who cant or dont want to convert all needed ebuilds to the new > multilib eclasses. > > multilib eclasses as a whole were a big failure, both for users (enough examples given here) and for developers (cause it requires understanding the eclasses). You should keep working on the spec, so we might be able to remove that crap some day. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSiOomAAoJEFpvPKfnPDWzTRUH/j5tWONLBh1bxCrsayrztYqn GbK7Fz8RBTnkoJhmYX8InKh8USEyCY9fkRcxWgF2rcF801u8hhFwpXEzf5kTISMb ctshmuyY5pS8e9IavyYY6VOTGmT2p9rxMpBVoDMn6Jf3hDwA2T/cY+W/QE1UGPF2 WVmdUAGFjPEaVJzMkgEgkCtoPhlqmPpHXrmhMKUvMNOtTdyNKSpqy+/ViUSZPp+J zkHg3UyO5ROF0OTgXJLFT4gx+yR85b8IHrBdcfoAXFaAw7AU1ycJuZ2zHDCgzcjC X4YTdSDoUAbxUpXf3cab13wRnudsGDUPfXD8lIb/20aPHnkKgjlHl+Otp3AnYco= =tTTR -----END PGP SIGNATURE-----