Re: [gentoo-user] Sweet Sweet Portage

[james]

On 08/16/2016 02:49 PM, Fernando Rodriguez wrote:
> On 08/15/2016 06:02 PM, james wrote:
>> Well,
>>
>> I brought this up before. No need for argument, just test it out
>> for yourself.
>>
>> Multiple times (over the last few weeks) I have run  'emerge -uDNvp @world' and there are issues to deal with manually.
>>
>> For example 'One or more updates/rebuilds have been skipped due to a dependency conflict', type of fudd and other types of fudd is the result, not all the time, but maybe 50% of the time.
>>
>>
>> Now, routinely, all I do is immediately issue this command
>> 'emerge -uDt @world' and go have a coffee.  An AMD 8 core, 32G workstation does it's thang, leaving me a with just a smile after the work is complete. No other actions, nadda, ziltch. Immediately, I then run  'emerge -uDNvp world' (again, and routinely I get::
>>
>> "These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>> Total: 0 packages, Size of downloads: 0 KiB"
>>
>>
>> Just try it for yourself. It's like clockwork now. Smooth. I have over 1500 packages installed on a mostly stable but hacked out /usr/local/portage/ and maybe 10% of the packages, that are much newer, but portage is sweet, sweet, sweet now. There is inherent magic now, but,
>> I do not have time to ferret it out. Sure I can dive in, manually,
>> and I have done this to fix things, but, 'emerge -uDt @world' fixes things, automagically; dozens of times as I update 3 or 4 times a week.
>>
>>
>
> I don't know exactly what's going on but I think something is wrong so it's not
> so sweet. I think you got a conflict that's not being resolved and not being pulled
> by the second command. What happends if you add --with-bdeps=y --backtrack=30? Also
> try without the -p (I think it runs more code like autounmask etc so it may cause
> the extra output).
>
> Is clang/llvm stuff still popping up on the list of skipped packages? I remember a
> similar conflict around the time of your first post and it turned out that the latest
> stable clang blocks the latest stable libclc. So the tree is (still) broken. For most
> users it's not a problem because portage pulls the right version of clang but if you
> have clang on your world file it updates it to the latest and you get those conflicts.
> I fixed it by masking all versions of clang >3.6
>



Nope, but on gentoo-dev there is a big announce about LLVM(clang).

No issues with the system, I run the latest portage and when issues 
popup, granted that are easy to fix, manually 'emerge -uDt world' 
precludes the need to fix them. Afterwards, running 'emerge -uDNvp 
world' just comes back completely clean. NO idea what's going on,
but *I* have verified this now dozens and of times over the recent weeks.

Instead of running 'emerge -uDNv world' I simple run 'emerge -uDt world'
and the manual (trivial) items just dissappear, it runs to completion
and all is just spanky fine. I do not have the will, nore inclination to 
dig deeply, but the benefit is most wonderful. ymmv.


But follow the evidence

emerge -uDNvp world
<comes back dirty, blockers and other minor issues>
emerge -Dut world
<things run; finishes up and no blockers or other issues>

emerge -uDNvp world
<comes back clean *after using -uDt>

It's just that simple:: 3 commands, no others. fabulous!

<end of thread for me>
You don't believe me, then just ignore the thread. ymmv.


--nobody cares, as I'm done with this thread.
James