[ebuild R ] sys-devel/gcc-4.9.3:4.9.3::gentoo USE="cxx fortran (multilib) nls nptl openmp sanitize vtv%* (-altivec) (-awt) -cilk -debug -doc (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" 0 KiB [uninstall ] sys-devel/gcc-4.8.5:4.8.5::gentoo USE="cxx fortran (multilib) nls nptl openmp sanitize (-altivec) (-awt) -debug -doc (-fixed-point) -gcj -go -graphite (-hardened) (-libssp) -mudflap -multislot -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" [blocks b ] <sys-devel/gcc-4.9 ("<sys-devel/gcc-4.9" is blocking sys-devel/gcc-4.9.3) Ok, so now suddenly gcc (without revbump ... grml) blocks all older versions so they get removed. The commit that changes it is: commit 6fd83c0c338e901db4ba47ddb87f523482fedf33 Author: Mike Frysinger <vapier@gentoo.org> Date: Sat Mar 12 10:53:42 2016 -0500 toolchain.eclass: use versioned SLOT all the time which adds this line: + !multislot? ( !<${CATEGORY}/gcc-4.9 ) I have no idea what this means, and why rebuilding gcc now suddenly removes 'harmless' old versions that have been there for a long time. Bonus: with the changes to toolchain.eclass in e5fdfd991ec21885d4141440da97189f29dfa7b9 "toolchain.eclass: automatically select latest gcc-config profile when unmerging active version #529608" this now means that users get automatically upgraded to a new gcc version on install. This deviates from existing behaviour without explanation and causes lots of confusion
Enable "multislot" USE-flag for all your gcc versions. I have the same issue, this works for me.
this is WAI. complain to bug 174407, or enable USE=multislot.
If multislot behavior is now always-on, why is there a multislot flag, which seems to do nothing except disable the blocker? Why is there a blocker at all? Can this be explained or announced somewhere?
(In reply to Ben Kohler from comment #3) because people complain about a large # of compiler versions sticking around and cluttering their system. the old tradeoff was to only have one per-major version, but because of people pushing against dynamic SLOTs, that's no longer viable. hence the new tradeoff is to have a blocker to automatically expire older versions. the blocker is a sliding one -- it only applies to the latest stable version. so when gcc-5 goes stable, we'll adjust the "4.9" waterline to "5". if anyone has a reasonable tradeoff, feel free to propose one. thus far, no one has proposed anything at all.
To be honest, the use of USE=multislot doesn't seem appropriate for a USE flag. People are going to take the effort of rebuilding to not see a real change in installed files...
(In reply to Michał Górny from comment #5) > To be honest, the use of USE=multislot doesn't seem appropriate for a USE > flag. People are going to take the effort of rebuilding to not see a real > change in installed files... it is possible to edit /var/db/pkg/ to avoid rebuilding, albeit a bit dangerous. nonetheless, i need multiple compilers and most users only want the latest, so i don't see why multislot isn't a useful USE flag.
I might be totally misunderstanding this, but why is there a flag to enable slotting :? Is there specific reason gcc can't use the regular slotting mechanism? (ran into this last week as well, I have sys-devel/gcc:4.8.5 and sys-devel/gcc:4.9.3 in my world file, always do to keep the previous gcc version around).
(In reply to Simon from comment #7) see comment #4
*** Bug 583234 has been marked as a duplicate of this bug. ***
I hit it today, it took my couple of minutes to get to this bugzilla, because I haven't noticed that this was announced anywhere. To be honest I think this is bad change. I think the flag should be on by default.
(In reply to SpanKY from comment #8) > (In reply to Simon from comment #7) > > see comment #4 Thanks for the hint. What I don't really understand is why gcc would/should be different than any other package that has slots. Can you explain why it would be? (like I said, maybe I'm misunderstanding things)
I don't quite understand why "a large # of compiler versions" appears at all unless a user explicitly installed them. Aren't old versions removed with emerge --depclean ? I ran into this problem when I did need several compiler versions and tried to do a standard system upgrade. The default USE flags for gcc were changed, and this caused rebuild and an error message, which was not very easy to understand and eliminate.
(In reply to SpanKY from comment #4) > (In reply to Ben Kohler from comment #3) > > because people complain about a large # of compiler versions sticking around > and cluttering their system. the old tradeoff was to only have one > per-major version, but because of people pushing against dynamic SLOTs, > that's no longer viable. hence the new tradeoff is to have a blocker to > automatically expire older versions. > > the blocker is a sliding one -- it only applies to the latest stable > version. so when gcc-5 goes stable, we'll adjust the "4.9" waterline to "5". > > if anyone has a reasonable tradeoff, feel free to propose one. thus far, no > one has proposed anything at all. Following this thread I wonder if there aren't parallels with gcc versions building up and and a similar situtation with respect to kernel sources, which presumably accumulate rather faster for most people? If you can cope with unmerging the latter then why is it so very different to do housekeeping on gcc? Or are there hidden dependencies on a particular version of gcc for some apps?
Let's not close bugs before the problem is fixed ...
Why is this closed? The problem isn't fixed. SpanKY can you answer comment #11? (don't want to nudge the answer in a certain direction, that'y why I asked such an open question, but to elaboratie: I'm asking because it sounds like there's simply documentation missing on how multislot works, I wouldn't mind to address that myself)
(In reply to SpanKY from comment #4) > if anyone has a reasonable tradeoff, feel free to propose one. thus far, no > one has proposed anything at all. I propose that you explain how to remove older gcc slots via a pkg_posinst message. The blocker "solution" is worse than the problem it is trying to solve.
Maybe something like this. pkg_preinst() { has_version ${CATEGORY}/${PN}:${SLOT%/*} newslot=$? } pkg_postinst() { if [[ ${newslot} -ne 0 ]]; then ewarn "A new gcc slot has been installed." ewarn "Please switch to the new gcc slot using gcc-config." ewarn "Afterward, you can remove the old slot(s). For example:" ewarn " emerge --depclean ${CATEGORY}/${PN}" fi }
Another idea: Slot based on major version in the gentoo repository, and create an overlay for the ${PV} slots.
(In reply to Mike Gilbert from comment #18) > Another idea: Slot based on major version in the gentoo repository, and > create an overlay for the ${PV} slots. Since slotmoves were added, all slots are burned now and not reusable.
(In reply to Michał Górny from comment #19) > (In reply to Mike Gilbert from comment #18) > > Another idea: Slot based on major version in the gentoo repository, and > > create an overlay for the ${PV} slots. > > Since slotmoves were added, all slots are burned now and not reusable. Then use slot names different from the old ones. What is the problem?
Old removal no longer happens, and I think auto-upgrades are back to the way they were before.
To be clear, I was just presenting some alternatives. I'm fine with the current slotting scheme; just not with the weird blocker.
