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).





Reply via email to