I run portage-18.104.22.168 on the x86/13.0/developer profile. After about two weeks today I synced the tree and run 'emerge -e world'. Among the packages that were to be upgraded was icu, from 49.1.2 to 51.1. The soname in these two versions differs. Libxml2 is also present and it depends on icu (dev-libs/icu:=). However, emerge placed the libxml2 re-merge before the icu upgrade. This caused a state with libxml2 already re-merged and built against icu-49, icu later upgraded and libxml2.so unusable because of its dependency on libicuuc.so.49. As the '-e world' progressed further, the turn came to libxslt whose compilation failed because it links against -lxml2 which has unresolved library deps at the moment.
Now I'm not well versed in EAPI 5, but from the devmanual specs of it I conclude that libxml2's dependency on "dev-libs/icu:=" is correct, but 'emerge -e' doesn't honor that dep. I find similarities with my issue in bug 440392, but this is an '-e world' situation which should complete smoothly.
Now with the '-e world' terminated, I ran 'emerge --resume --skipfirst' to skip the libxslt build that I know would fail. But emerge returns this:
# emerge --resume --skipfirst
Calculating dependencies... done!
* One or more packages are either masked or have missing dependencies:
* dev-libs/icu:0/0= pulled in by:
* (dev-libs/libxml2-2.9.0-r2::gentoo, installed)
* The resume list contains packages that are either masked or have
* unsatisfied dependencies. Please restart/continue the operation
* manually, or use --skipfirst to skip the first package in the list and
* any other packages that may be masked or have missing dependencies.
Why does emerge take icu and libxml2 into consideration now? They had both been merged before the libxslt failure, so I believe emerge should now ignore whatever unresolved deps those two have.
It's also interesting that emerge notices the dep of libxml2 on icu now, but it didn't when the original '-e world' deps were being resolved. Maybe it's just a simple bug in the "--emptytree" feature.
Finally, it may or may not be wrong that emerge thinks libxml2 depends on icu:0/0=. There is no such icu version if I get things right.
The original problem (placing libxml2 before icu) could, hypothetically, be caused by circular deps. If you could suggest an efficient way to discover them, I'd make a good use of it.
Ah, this is important: before the original '-e world' I manually upgraded portage to the latest stable (22.214.171.124).
(In reply to comment #2)
> The original problem (placing libxml2 before icu) could, hypothetically, be
> caused by circular deps.
Yes, it's probably circular deps.
> If you could suggest an efficient way to discover
> them, I'd make a good use of it.
A couple of things might help mitigate the issue:
1) Do a normal update first, before using -e (that way there are fewer circular deps to deal with during the update phase)
2) Enable FEATURES=preserve-libs in make.conf, so that things like libxml2 continue to be usable after the icu update.