llvm-3.4.1 is not just a bug fix release. It adds some functionality changes like geometry shaders support for radeonsi driver in mesa. See patch [1] queued for mesa-10.1.4 for example. If you have llvm-3.4 and mesa with a mentioned patch, then just upgrading llvm to 3.4.1 will not automatically enable geometry shaders support in radeonsi driver. Mesa will need to be rebuilt to get new features. (Actually 3.4.1 is a bad example, because soname of libLLVM was changed by accident. This change will be reverted in llvm-3.4.2 release [2][3]. So 3.4.2 is a better example, because preserve-libs portage feature will not advise to rebuild mesa after upgrading llvm from 3.4 to >=3.4.2). Some notes: - Looks like no need to bump subslot further for 3.4.2 and (hopefully) for future minor updates of 3.4 branch. - All of this make sense only if subslot operator on llvm dependency will be added to mesa ebuild (bug 510774). [1] http://cgit.freedesktop.org/mesa/mesa/commit/?h=10.1&id=16dfaf495a166945d11e024c5aee0b354f331727 [2] http://llvm.org/viewvc/llvm-project?view=revision&revision=208829 [3] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/072858.html
(In reply to Alexander Tsoy from comment #0) > Some notes: > - Looks like no need to bump subslot further for 3.4.2 and (hopefully) for > future minor updates of 3.4 branch. Hmm.. Since soname was changed in 3.4.1 and changed back again in 3.4.2 (not released yet), maybe it make sense to bump subslot for 3.4.2 as well? > - All of this make sense only if subslot operator on llvm dependency will be > added to mesa ebuild (bug 510774). Since soname was changed, maybe this makes sense not just for mesa?
This brings the whole discussion about what exactly purpose of subslots are. I'll bring this to gentoo-dev@.
3.4.2 is the only 3.4 version left in tree (with soname changed back), so we have been OK here for some time
