1 |
Alan McKinnon <alan.mckinnon <at> gmail.com> writes: |
2 |
|
3 |
|
4 |
|
5 |
|
6 |
> > Ah excellent point, but the build did not move forward with:: |
7 |
> > ' emerge -uvDN world' either. With the --tree it did move forward with |
8 |
> > the build update. In the first attempt usually the packages to be built |
9 |
> > are listed, conflicts or blockers. |
10 |
|
11 |
> But you didn't run |
12 |
> emerge -uvDN world |
13 |
> You ran |
14 |
> emerge -uvDNp world |
15 |
> why won't move forward, ever |
16 |
|
17 |
Nope. |
18 |
|
19 |
I ran 'emerge -uvDNp world' |
20 |
and then 'emerge -uvDN world' |
21 |
No point delineating that detail, or so I thought |
22 |
|
23 |
> > None of these 3 packages where listed in the first attempt to see |
24 |
> > what needs to be built:: |
25 |
> > Not 'sys-devel/llvm', nor 'sys-devel/clang', nor 'media-libs/mesa'. |
26 |
|
27 |
> >>>>>> Emerging (1 of 3) sys-devel/llvm-3.7.1-r3::gentoo |
28 |
> >>> I did nothing manual in between. Explanations? |
29 |
> >> portage is doing what's expected. You don't have -a in the command line |
30 |
> >> and there's nothing stopping portage from moving forward with the build. |
31 |
> >> SO it moved forward with the build. |
32 |
> > |
33 |
> > Yes, nothing to do with 'media-libs/jasper' nor 'gdk-pixbuf'. So I guess the |
34 |
> > --tree option got rid of the these (conflicts issues. My point is that this |
35 |
> > is remarkably better than how things worked in the past (but not certain |
36 |
> > when these enhancements were made). |
37 |
> |
38 |
> But you introduced two significant changes in you command line |
39 |
> removed -N |
40 |
> added -t |
41 |
|
42 |
> It's unsurprising you got different behaviour |
43 |
|
44 |
true, but the -u was in both and a complete different set of |
45 |
packages was considered, by portage, and only one was able to |
46 |
move forward (note the -p was not in the second entry, despite |
47 |
my not including that detail). |