Currently there is no stable working gcc-config ebuild in portage. sys-devel/gcc-config-1.3.6-r4 fails with FEATURES="collision-protect". sys-devel/gcc-config-1.3.7-r5 is marked unstable. I cannot get a working gcc-config without overwriting files that do not belong to this ebuild unless I use the unstable ebuild. Hmm... :-( Reproducible: Always Steps to Reproduce: See Bug 72866, Bug 72745 and Bug 73331. Expected Results: We need a stable and working gcc-config! Either fix gcc-config-1.3.6-r4 or mark gcc-config-1.3.7-r5 stable ASAP.
dont file new bugs when you already know they've already been filed elsewhere *** This bug has been marked as a duplicate of 72866 ***
Pardon my ignorance, but I am pointing to the fact that there is no stable working ebuild right now and that we do need to solve this. This is _not_ a duplicate of Bug 72866. That fix is not useful when someone is using _stable_ ebuilds only on his/her system - until that ebuild is marked stable. If it is not possible to mark that one stable now, then the currently stable one should be fixed as well.
stop using the collision protect then gcc-config-1.3.7 isnt ready for stable just yet and i'm not willing to change 1.3.6 since i have no idea how 1.3.6 will react
Huh? Do you mean this it is correct and safe for ebuilds to overwrite files that do not belong to them? OK, then FEATURES="collision-protect" is a redundant option and should be removed from portage. Otherwise this is a bug that needs to be fixed. Marking this bug as fixed will not solve the problem, however. It will just confuse people who are seeking help in bugzilla. :-/
Grr... What exactly are you proposing ? To add bug fix in stable version ? Forbidden: it's not exactly trivial change and will make changed package unstable. To mark package where bug is fixed stable ? It's not there yet. There are simple procedure for bug-fixing: once bug is identified fix is added to *next* version of package - unless it's critical security bug. Once next version of package is deemed stable bug is fixed in stable branch. Now: this bug is already fixed in unstable branch and it's not critical security bug as well. So there are literally nothing to do: bug *has* clear workaround for time being, it *is* fixed in next version (currently marked unstable) so there are literally nothing to do. If every bug will be fixed in stable branch then there are will be *no* stable branch - testing bugfies is why we have unstable branch in first place for god's sake. So *any* bug with description "it does not work in stable version but works in next unstable version" should be automatically closed as "WORKSFORME" - unless problem is so severe that there are no simple workaround or security implications are dire indeed.