On Sat, May 16, 2015 at 6:20 AM, Neil Bothwick <n...@digimed.co.uk> wrote: > On Sat, 16 May 2015 13:10:21 +0300, gevisz wrote: > >> > I'm afraid I cannot agree with you on this. On older PCs I would >> > rather did not have to install abi_x86_32 for packages that I don't >> > need to. The granular approach suits me better and also aligns >> > better with the light-footed Gentoo approach. >> >> With this "light-footed approach" I had about two full-screen rubbish >> in my /etc/portage/make.conf file and kept adding on almost every >> update. > > Unless your screen is IMAX-sized, two screens of text is a lot more > lightfooted than add extra libraries to nearly 200 packages - and most > of that text is comments anyway. >
Well, it can be a lot more than two screens of text. I have 1300 lines of package.use, almost all of it for abi_x86_32. I suspect that this the result of stuff like steam, wine, android-sdk-update-manager, and eternal-lands - all packages that involve graphics libraries and toolkits with huge dependency trees. I still recommend the per-package approach, but I really think we're barking up the wrong tree here. I don't see the depgraph itself as the issue, or the ability to tweak flags per-package. I really see the bigger problem as the combination of two things: 1. Portage's error messages when it is unable to produce a resolution are really confusing - somewhere in that wall of text are some clues that might eventually lead you to the likely 1-3 use flag or keyword tweaks that will fix the whole mess, but good luck finding it. Your example isn't even a terribly bad one - when you get those errors with something like qt it goes on forever. 2. Portage requires non-package-default use flags to always be specified explicitly either globally or per-package. I don't have to put qt in my world file to install kde, because portage knows it is needed and just installs it, and removes it when it is no longer needed. However, if something needs the qt use flag, portage can't treat it the same way. Now, there are certainly reasons why both of these issues exist. Solving them may not be trivial, and in the case of #2 perhaps there may be unintended consequences like unnecessary package rebuilds to progressively add/remove flags. And, of course, somebody has to do the work and since I'm not busy writing patches to portage right now I'm not going to complain too much about it. However, I really think that these are the real issue here. That, and automatically solving depgraph issues isn't trivial. -- Rich
