[binary 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" 40,659 KiB So gcc has just grown a new feature without revbump (vtv useflag/feature) Can you please properly bump packages when making changes that affect features and installed files?
use --newuse if you care. otherwise, the behavior is the same.
You're doing multiple unusual things in one go: - change installed files without revision bump - change functionality without revision bump - change stable ebuild without revision bump The common consensus (especially from a QA perspective) is "Don't do that please". Especially the combination of changing long-standing eclass behaviour (#582504) and changing the ebuild causes lots of unexpected behaviour, while the lack of a revision bump gives users no choice to avoid or review these changes. And I think we all agree that surprises are bad, especially when "the same" ebuild suddenly has different useflags, wants to unmerge your old gcc, and you have no idea how all of that makes any sense.
which is all behind a USE flag. anyone rebuilding the current version will see the change in the USE state. if they don't want vtv, they can set USE=-vtv, then the compile & install state is the same as before the flag existed. when adding new USE flags, it's not uncommon to not bump because people are used to leveraging --newuse/--verbose output and the PM highlighting changes. otherwise you couldn't make any changes to profiles w/out revbumping a crap ton of packages too.
> - change installed files without revision bump there is no difference to installed files before and after this change. the default behaviour was to install libvtv and it's still is. > - change functionality without revision bump there is also no change in default functionality before and after the change > - change stable ebuild without revision bump and? would you like us to revbump every stable ebuild whenever we make eclass changes? even without a new USE flag this wouldn't warrant a revbump. the only time we bump the revision on gcc is for major issues that affect a large portion of users. Quoth the devmanual: > Ebuilds should have their -rX incremented whenever a change is made which > will make a substantial difference to what gets installed by the package — by > substantial, we generally mean "something for which many users would want to > upgrade".' [...] In particular, this applies if the package has a > substantial compilation time; developers should use their best judgement in > these circumstances. in this case we're talking about a change to an experimental feature only enabled through a non-standard compiler flag that was broken for two years without anyone noticing. absolutely no one will be affected by this.
