Due to not-so-properly implemented(without proper support from package manager) USE-dynamic[1] flag "multislot" now we have metadata inconsistency that violates PMS and can be point of breakage for other PMs, that follows PMS stricter than portage. QA team discussion about multislot issue - http://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Summaries#Multislot_issue As usual - no talk here(unless it's about the whole issue itself), just link apropriate bugs to the tracker. [1] - Bug #174407 gives some background about the USE-dynamic slots
Example of badly behaviour in some tools: bug #434536
I never got a reply to the mail I sent, is masking with an appropriate warning acceptable?
(In reply to Ryan Hill from comment #2) > I never got a reply to the mail I sent, is masking with an appropriate > warning acceptable? Masking the whole USE="multislot" ? Yeah, i think it's fine - SLOT variable in all ebuilds has persistent value with disabled USE="multislot".
It should only be package.use.masked, otherwise sys-boot/grub will be affected where the flag is used properly (i.e. without changing metadata).
+ 01 Oct 2014; Sergey Popov <pinkbyte@gentoo.org> package.use.mask: + Mask USE='multislot' in sys-devel/binutils as well, bug #507808
Er, so now we can't have SLOTted toolchain parts?
(In reply to Jeroen Roovers from comment #6) > Er, so now we can't have SLOTted toolchain parts? You can unmask USE="multislot" and use it on your own. But until the breakage will be fixed(by, for example, changing metadata concept in portage) it should not be allowed to be enabled for ordinary users.
@jer: more specifically, we can have SLOTted toolchain parts. The problem is having the SLOT be redefined by a USE flag, as is the case for USE=multislot.
No more bugs open. Closing the tracker.
