Looking in the mesa ebuild I found that RDEPEND on >=sys-devel/llvm-3.6.0:0 but new llvm are slotted in :4 eg.: sys-devel/llvm-4.0.0:4 and so mesa will try to pull in older llvm versions causing conflicts
Are you talking about mesa-13.0.x ebuilds? As a general rule you can't expect a mesa version to support llvm versions released at a later date. (and here I mean the date of the initial release of a particular major version of mesa, not later minor revisions). Taking that into consideration, not even mesa-17 would have been guaranteed to support llvm-4 as mesa-17.0.0 was released on February 13 while llvm-4.0.0 on March 13. However, since at the time of the mesa release llvm was already at release candidate stage it maintained binary compatibility with the final release so mesa-17 does support llvm-4. Now, if you look at the mesa-17.0.2.ebuild it already has support for llvm 4.
Please attach an emerge --info and the full output of the blocker. Do you by any chance have bug 613700 ?
(In reply to Matthias Maier from comment #2) > Please attach an emerge --info and the full output of the blocker. > > Do you by any chance have bug 613700 ? When trying to update I get: * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-devel/llvm-4.0.0:4/4::gentoo, ebuild scheduled for merge) pulled in by >=sys-devel/llvm-4 required by (sys-libs/libcxxabi-4.0.0:0/0::gentoo, ebuild scheduled for merge) sys-devel/llvm:4[gold] required by (sys-devel/llvmgold-4:0/0::gentoo, ebuild scheduled for merge) >=sys-devel/llvm-4 required by (sys-libs/libcxx-4.0.0:0/0::gentoo, ebuild scheduled for merge) (sys-devel/llvm-3.9.1-r1:0/3.9.1::gentoo, ebuild scheduled for merge) pulled in by >=sys-devel/llvm-3.6.0:0=[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32 (-)?,abi_s390_64(-)?] (>=sys-devel/llvm-3.6.0:0=[abi_x86_64(-)]) required by (media-libs/mesa-13.0.5:0/0::gentoo, installed) ~sys-devel/llvm-3.9.1[clang(-),debug=,python?,static-analyzer?,llvm_targets_AArch64?,llvm_targets_AMDGPU?,llvm_targets_ARM?,llvm_targets_BPF?,llvm_targets_Hexagon?, llvm_targets_Mips?,llvm_targets_MSP430?,llvm_targets_NVPTX?,llvm_targets_PowerPC?,llvm_targets_Sparc?,llvm_targets_SystemZ?,llvm_targets_X86?,llvm_targets_XCore?,abi_x8 6_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (~sys-devel/ll vm-3.9.1[clang(-),-debug,python,static-analyzer,llvm_targets_AMDGPU,llvm_targets_BPF,llvm_targets_NVPTX,llvm_targets_X86,abi_x86_64(-)]) required by (sys-devel/clang-3. 9.1-r100:0/3.9.1::gentoo, ebuild scheduled for merge) >=sys-devel/llvm-3.6.0:0/3.9.1=[abi_x86_64(-)] required by (media-libs/mesa-13.0.5:0/0::gentoo, installed)
Solved masking <llvm-4 and <mesa-17, portage isn't smart enough to do itself.
