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 D6723138CCA for ; Mon, 30 Mar 2015 11:15:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 686D4E0960; Mon, 30 Mar 2015 11:15:06 +0000 (UTC) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3CAB5E0946 for ; Mon, 30 Mar 2015 11:15:05 +0000 (UTC) Received: by wgra20 with SMTP id a20so169744888wgr.3 for ; Mon, 30 Mar 2015 04:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OmS8VydFt8UK/bctiGxOBw2ohqqgFFoNvPXc/IjmwDQ=; b=SCEoOAOQVF60LOpKSfT0dOuYspf5gzf2j+Ao/Qs3TQwifP6dPl/Xjvr0IVa1WhKgQi WmS8Tfrf174GMN9wyZioB8RxHvk+oQ2/C+QZjcacHUOyHTg9CHXsdFNR2VMKlTu9Cut6 Y3jNjfAP3OiQa2gdLbjLj0vjXrr0UWRmonDbiRhOvdtWqkhXPmdmtP0xFWpaup9RaNw2 Qjk8jbrHdnuI7wzRk1kOuQql9TA5i7HfLlCs5yAKm7Ak5DW/pPUWn0JEAVa9XDv0Vc4P O/S4jqeRVWCn4MaHZtmRHCGRHGlgp6TWC3Rs0eoNw8WpbACOPHwu9HJ0y/LuwpqlAZJP 3qwQ== X-Received: by 10.194.2.145 with SMTP id 17mr61380546wju.79.1427714104023; Mon, 30 Mar 2015 04:15:04 -0700 (PDT) Received: from [172.20.0.41] (105-237-231-92.access.mtnbusiness.co.za. [105.237.231.92]) by mx.google.com with ESMTPSA id ev7sm15245399wjb.47.2015.03.30.04.15.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2015 04:15:03 -0700 (PDT) Message-ID: <5519302F.5070906@gmail.com> Date: Mon, 30 Mar 2015 13:14:55 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: This nite's switch to "full multilib" References: <5517CCCC.90800@seismic.de> <551881EA.7040705@gmail.com> <5519103D.8020200@xunil.at> <201503301023.30797.michaelkintzios@gmail.com> <551919CF.70200@gmail.com> <55191F2F.4070906@xunil.at> <55192205.4060702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 1d97a280-2986-4818-8789-78d05d65aeb5 X-Archives-Hash: b028d41d71227a9caf314af9361d762e On 30/03/2015 12:42, Holger Hoffstätte wrote: > On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote: > >>> OK, then so why do I have to edit files to tell the system to USE this >>> and that after the system tells me it needs that ... ? >>> >>> Why isn't this taken care of within portage itself? >>> >>> I don't *want* to decide 32bit or not ... (I like that I *can* ...) >>> >>> I want a (mostly) stable and current linux system with the necessary >>> choices done by the maintainers ... if Skype needs it ... ok, then make >>> that a dependency/requirement somewhere ... but why force me to set that >>> (for so many packages) ? >> >> OK, think it through first. > > Sure thing. > >> You want skype. Skype is 32bit. So far, we're good. You put an entry in >> package.use to enable abi_x86_32 for skype. > > Except..at that point you would have already failed. That does not compute. Please explain. > > There is no good reason whatsoever why portage shouldn't be able to treat > this like a transitive required USE flag requirement, percolating through > all libs from the toplevel requirement's dependency tree. Correct, there is no good reason why portage *can't* do that. There is a very good reason why portage *won't* do that, it is not the gentoo way and it goes against gentoo's social contract. Portage does not override your choices, and it certainly does not allow one single ebuild to automagically change the behaviour of multiple other ebuilds. The correct way to bring about changes in behaviour is to add your global choices to make.conf (which is outside the control of the tree), or to add your explicit changes to package.* Portage's default behaviour when confronted with incompatible settings has always been to detect them, and print the output to the console telling you what to do. Now, there is a helper function that you as the system owner can enable if you trust portage and the tree to always make the correct decision - autounmask. You can run it with -p to get a full list that you can edit before running it for real, or you can just let portage go ahead and make the changes it feels are correct. But this is not default behaviour and for very good reason. I get the sense that those who are complaining about abi_x86_32 in this thread are mostly not complaining about what portage does, they are complaining about the number of entries they have to make to portage.use I don't understand why you are advocating a dramatic change in portage's behaviour from what it has done for years. Yes, this latest feature does require some work from you. You have been doing this same work for ages, the main difference being that this time it's a large amount of once-off work. > > In fact it should do so automatically when the ebuild declares the abi_x86_32 > constraint from the start, without requiring the user to do anything. So you want a single ebuild to trigger a tree-wide change in behaviour? I don't think that's a good idea > > There are other reasons why coupling the native and 32-bit worlds together is > a bad idea in the long-term, regardless of understandable technical reasons > and good intentions. > > So yeah: think it through first. I already did. Refer this post. I think I thought about it in ways that you have not considered yet. -- Alan McKinnon alan.mckinnon@gmail.com