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 BA683138821 for ; Wed, 1 Apr 2015 17:28:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BF9DEE0B18; Wed, 1 Apr 2015 17:28:46 +0000 (UTC) Received: from smtp102-3.vfemail.net (eightthree.vfemail.net [96.30.253.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A9927E0B03 for ; Wed, 1 Apr 2015 17:28:45 +0000 (UTC) Received: (qmail 21659 invoked by uid 89); 1 Apr 2015 17:28:44 -0000 Received: by simscan 1.4.0 ppid: 21651, pid: 21655, t: 0.1619s scanners:none Received: from unknown (HELO bXlzZWw=) (aHNAdmZlbWFpbC5uZXQ=@ODcuMjQ0LjIzMy4xNTM=) by mail.vfemail.net with ESMTPA; 1 Apr 2015 17:28:44 -0000 X-Received: id 9482440036 for ; Wed, 1 Apr 2015 19:28:42 +0200 (CEST) Date: Wed, 1 Apr 2015 19:28:42 +0200 From: =?ISO-8859-2?B?UvNiZXJ0IMhlcvJhbnNr/Q==?= To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: This nite's switch to "full multilib" Message-ID: <20150401192842.0c50d878@amit.mysel> In-Reply-To: <5519302F.5070906@gmail.com> 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> <5519302F.5070906@gmail.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.27; x86_64-pc-linux-gnu) 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 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 4d2924a1-8d2e-41a8-8873-03a07f2c6f9a X-Archives-Hash: 419b9dde7ad61a9b87183d880bcb40c9 On Mon, 30 Mar 2015 13:14:55 +0200 Alan McKinnon wrote: > On 30/03/2015 12:42, Holger Hoffst=E4tte wrote: > > On Mon, 30 Mar 2015 12:14:29 +0200, Alan McKinnon wrote: > >=20 > >>> 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) ? [...] > > 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. >=20 > 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. >=20 > 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.* It depends what you see as a user choice. In my opinion by writing 'emerge skype' to the console the user clearly states his choice to install skype. If he actually cares what that would mean for his system he can use --pretend or --ask option together with --verbose and tweak USE flags if and only if he does not like it. So user has still full control over his system. > 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 We could declare USE settings e.g. in make.conf as overridable by automatic USE dependencies so portage would not see it as incompatible. On the other hand package.use could be non-overridable thus allowing the user to have control over portage choices. > 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 Big advantage of automatic deps over --autounmask is that auto deps would not mess with user configuration files in /etc. Changed USE flags would be stored internally by portage. Robert --=20 R=F3bert =C8er=F2ansk=FD E-mail: openhs@tightmail.com Jabber: hs@jabber.sk