Re: [gentoo-user] At last! A Qt5 version of KMail-2 - but here be dragons!

[Michael Mol]

On Sunday, December 18, 2016 2:59:36 PM EST Peter Humphrey wrote:
> This morning I ran my usual daily update and was presented with a long list
> of kde-app packages, including KMail-2. The only problem was four blocks
> that portage couldn't sort out on its own, so I evicted the existing
> versions with emerge -C and continued.
>
> Then kleopatra failed to build, as in bug 602924. The fix there worked (I
> should call it an evasion really) and kleopatra built ok. Then, on
> continuing with emerge -uaDvU, another whole load of blocks arose, mostly
> from portage trying to pull back in the versions of packages that had just
> been superseded.
>
> There seemed to be no way out of that, so I took my sledge-hammer and
> started an emerge -e world. No blocks were reported, so I think I might be
> getting away with it. I'm about half-way through so far, and I'm writing
> this via webmail.
>
> So, tread warily, anyone who is offered 16.12.0 versions of 148 kde-apps
> packages.

Try running emerge with, e.g. --backtrack=1000.

So, I've been running with a massive set of package.unmask for all of KDE-
Frameworks, Qt, Plasma and KDE-Applications. I also have a cron job handling 
updates for me every evening. By an large it's worked fine...until a couple 
weeks ago.

At that point, I wound up with a ton of slot conflicts that didn't make any 
sense to me, but I figured they were tree issues that would work themselves 
out. They didn't, and were getting in the way of a security update I needed, 
so finally I dove in and devoted some time to it this morning. I tried 
unmerging all of dev-qt/*, but that didn't solve the problem completely; 
portage was still unable to work its way around a simple upgrade from perl 
5.22 to 5.23. Once I threw in --backtrack=1000, it started swimming right 
along.

It *seems* like the default backtrack value, 3, is simply too low for someone 
like me who runs with --deep and --with-bdeps=y in EMERGE_DEFAULT_OPTS; once I 
bumped the backtrack value, portage was able to work its way through the 
dependency tree just fine.