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 5A0DD58973 for ; Thu, 11 Feb 2016 23:51:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 815E421C004; Thu, 11 Feb 2016 23:51:05 +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 75E8BE080A for ; Thu, 11 Feb 2016 23:51:04 +0000 (UTC) Received: from [192.168.1.2] (c-73-53-75-119.hsd1.wa.comcast.net [73.53.75.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zlg) by smtp.gentoo.org (Postfix) with ESMTPSA id 96A11340C1C for ; Thu, 11 Feb 2016 23:51:03 +0000 (UTC) Subject: Re: [gentoo-dev] "Lazy" use flags? To: gentoo-dev@lists.gentoo.org References: <56B9E646.4040206@gentoo.org> <20160209213532.6354204c.openhs@tightmail.com> <20160210210035.02a94a20.openhs@tightmail.com> <56BC0403.80807@gentoo.org> From: Daniel Campbell X-Enigmail-Draft-Status: N1110 Message-ID: <56BD1E65.3080100@gentoo.org> Date: Thu, 11 Feb 2016 15:51:01 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 39de6a45-13b0-48c0-93a5-ba0ec4894ed4 X-Archives-Hash: b9cc3f0954e935e5fbdfc2ec816e9b70 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/11/2016 04:59 AM, Rich Freeman wrote: > On Wed, Feb 10, 2016 at 10:46 PM, Daniel Campbell > wrote: >> >> On 02/10/2016 06:51 PM, Rich Freeman wrote: >>> >>> Ditto for stuff like 32-bit support for half the libraries on >>> your system when you're using something like wine. Just don't >>> set the flag except explicitly if you actually need it >>> somewhere, and it will get pulled in where it is needed, and >>> go away when it is no longer needed. >>> >> >> re multilib, under what configuration does abi_x86_32 get set on >> its own? With a blank ABI_X86 variable in make.conf? Every >> 32-bit package I've ever pulled in has needed that flag set, and >> I've had to manually set it until blockers are resolved. I've not >> set -abi_x86_32 globally or anything like that. > > We're talking about a proposed portage feature which hasn't been > written yet. None of the behavior described in this thread happens > today. Right now all those abi_x86_32 flags are set explicitly, > which is why my package.use file is about 10x larger than it used > to be. I'm contemplating splitting out the 32-bit stuff into a > separate file and just nuking it every 6-months and allowing > portage to re-create it to try to keep it somewhat manageable. > > And that is the inspiration for this. The current design mixes > true user preferences with stuff added by auto-unmask needed just > to fulfill dependencies. Users should be easily able to > prioritize the one above the other. Indeed, maybe I have a few > 32-bit library preferences which are explicit and now if I go to > nuke then every six months I have to keep track of which ones are > which. > > With the proposed lazy use flags then for the most part 32-bit > support would be automagic for most users. > Okay, I wasn't sure if you were talking what's already here or the main topic. Thanks for clarifying. I think lazy USE would be a big plus for multilib users. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWvR5kAAoJEAEkDpRQOeFwfCoP/2bdwfRQOSG/OZ0HtcTZCGzV UKM8i3Z1kPL7QVgDA24kDDvPwyPDsGIm9x0/fe/UeDlQ3tkSqhQvbBukNXEW0gaJ qMNQBPmnGfGOhr0o0VylvMGZCq4IKGW8hQdBtjA/QTCSKiASAM1j+IjlvBSk1n6V G+eqoGdY50xF8C8tix1ozmA1ZHP49sU1nE1Dnzg+AA3AESgfrxJ2ys9ccB7vwIny dWD5HXzTNjhc4OkiqWSBfO9CESEPe/vKbk5la7HxdVB/auKm52A/O81Bs+8YXHlL IB3k81lpEY08O7lfVzfJqj0uN+7yF6v6pRVwDdnDGbJQCbun5hfmQBlmGYHEEDMf z2SI6eIPkYWlonEgmBOkvu1fZP7gdXs9gPHnsGd3QxdjBiqOyb3AckqcxQDiczKf 1xDs8isXenEtSV4MTjO/JwyJT1sgORn3y+iFvUMDdOtjWFAs4xHMZRiqcgQ9hn+3 Q7PgB1VLw85THQBFtE2s4FtM9H2I9oRPVDM10OEXFiIVtH2Kkh9LWHr/CdkpGt9I MEDt0HH9m6so2JW407BX8nhT6eL8QZCOEzm7zjfMeFNFbbctRtIEhj3DiSPvYIq+ OyRJ7f3zqygwV+wH09y9fmCJ/bJzrIsRARsAw9V/lW4MLLRQ3IfqWfsQG/BSYFWL CLLROLSNbTQR16QxUiJq =/IrH -----END PGP SIGNATURE-----