Alan McKinnon <alan.mckinnon <at> gmail.com> writes:
> > Ah excellent point, but the build did not move forward with:: > > ' emerge -uvDN world' either. With the --tree it did move forward with > > the build update. In the first attempt usually the packages to be built > > are listed, conflicts or blockers. > But you didn't run > emerge -uvDN world > You ran > emerge -uvDNp world > why won't move forward, ever Nope. I ran 'emerge -uvDNp world' and then 'emerge -uvDN world' No point delineating that detail, or so I thought > > None of these 3 packages where listed in the first attempt to see > > what needs to be built:: > > Not 'sys-devel/llvm', nor 'sys-devel/clang', nor 'media-libs/mesa'. > >>>>>> Emerging (1 of 3) sys-devel/llvm-3.7.1-r3::gentoo > >>> I did nothing manual in between. Explanations? > >> portage is doing what's expected. You don't have -a in the command line > >> and there's nothing stopping portage from moving forward with the build. > >> SO it moved forward with the build. > > > > Yes, nothing to do with 'media-libs/jasper' nor 'gdk-pixbuf'. So I guess the > > --tree option got rid of the these (conflicts issues. My point is that this > > is remarkably better than how things worked in the past (but not certain > > when these enhancements were made). > > But you introduced two significant changes in you command line > removed -N > added -t > It's unsurprising you got different behaviour true, but the -u was in both and a complete different set of packages was considered, by portage, and only one was able to move forward (note the -p was not in the second entry, despite my not including that detail).