On Mon, 30 Mar 2015 13:14:55 +0200 Alan McKinnon <alan.mckin...@gmail.com> wrote:
> 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) ? [...] > > 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.* 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 -- Róbert Čerňanský E-mail: ope...@tightmail.com Jabber: h...@jabber.sk
