Ruby team, I'm required to run a ruby21 application. Ruby21 has not been stabilized so I had to keywords few dependences with target_ruby21 available. Somehow, all ruby ebuilds lose ruby 21/22 flags after its stabilization so I have to adjust keywords every time and pull unstable versions. As a recent example, here are 2 ebuilds: dev-ruby/execjs-2.2.2 (used to have ruby21 and ruby22) ~dev-ruby/execjs-2.5.2 USE_RUBY="ruby19 ruby20 ruby21 ruby22" or dev-ruby/ruby2ruby-2.1.3 (ruby21 ruby22 disappeared after its stabilization) ~dev-ruby/ruby2ruby-2.2.0 USE_RUBY="ruby19 ruby20 ruby21 ruby22" It makes me very difficult to keep my keywords up to date and I hope to find a better way so it would be convenient for both users and developers. After quick search I found "use.stable.mask" option. Wouldn't it better to use it instead? Thanks.
<hat=QA> Agreed, is there a reason why stable.use.mask isn't being used for this? Pulling use flags seems pretty severe. </hat>
Short answer: Don't mix stable and unstable. It is not supported. Long answer: We create stable candidates and thus drop later testing rubies from these version and add them back in a later revision/version. Use.stable.mask is not an option here, because it will lead to the stabilization of packages without proper testing for later rubies by arch teams. Later untested rubies might create some spontaneous breakage, which we want avoid. See for example dev-ruby/i18n, which is broken for ruby22 but works for earlier rubies. Ruby 2.1 is to be stabilized soon, see bug #518094. <hat name='QA'> I'm not aware of any policy that is violated here. We just don't support mixed setups. Either keep with stable ruby or go testing. </hat>
(In reply to Manuel Rüger from comment #2) >See for example dev-ruby/i18n, which is broken for ruby22 but works for earlier >rubies. I'm not sure how this illustrates your point, it would seem that if it is broken in ruby22 it shouldn't have a ruby22 flag, stable, testing, or otherwise. > <hat name='QA'> > I'm not aware of any policy that is violated here. We just don't support > mixed setups. Either keep with stable ruby or go testing. > </hat> No policies are being violated here, this was just me officially asking for why something that looks wierd is happening.
(In reply to Rick Farina (Zero_Chaos) from comment #3) > (In reply to Manuel Rüger from comment #2) > >See for example dev-ruby/i18n, which is broken for ruby22 but works for earlier >rubies. > > I'm not sure how this illustrates your point, it would seem that if it is > broken in ruby22 it shouldn't have a ruby22 flag, stable, testing, or > otherwise. The concern is more that code paths that were not tested on stable before will suddenly be exposed once the use mask is lifted. The fact that a package worked in testing with e.g. ruby21 doesn't mean that it will, even when all dependencies are met. By taking the approach that we take we get to test each package as it moves to stable. It does have the drawback of being a bit more work on our side, and of not supporting the scenario described by Anton. Does QA have a point of view on unmasking use.stable.mask flags?
(In reply to Anton Bolshakov from comment #0) > Ruby team, > > I'm required to run a ruby21 application. Ruby21 has not been stabilized so > I had to keywords few dependences with target_ruby21 available. We are currently in the process of marking Ruby 2.1 stable in bug 518094. Once this is stable we'll try to only file bugs for package versions with ruby21 included, and we'll start the stable process for Ruby 2.2 as well.
I'm sure that ruby team have their own valid reasons. But please look at the problem from user's perspectives as well. There are few points from a user point of view: - by saying "not supported" you really mean "not tested fully". Gentoo was always about the choice. The lack of USE_RUBY flags does not give users a chance to test stable ebuild and help to find all bugs in a next ruby version before gentoo devs stabilize it (and it's too late to test). I mean, users can always copy all ruby ebuilds to a local repo, add it but it is not an option obviously. - There is also a straightforward analogy with PYTHON_TARGETS or even KEYWORDS. The long list of not properly tested arch flags is there and anyone can test it using "typical" way (keywords, use flags). I don't quite understand how it can be "suddenly exposed". - The last point I already mentioned. I'm forced to keep adjusting ruby deps to a random next version which might and will break my application at some point. Instead, I would like to see a gradual process of stabilization of my environment and keep using packages which I have tested. In short, it is extremely difficult for users to test a next "unstable" ruby version. The current "stable" Ruby19 has been absolute 6 months ago. It should be an option (at least) to test the recommended version 2.2. Perhaps, the suggested change would allow to speed up the process of stabilization as well. Please consider. Thanks.
For ruby22 we have decided to go with the same approach as python and use.stable.mask the ruby22 USE flag. This means we no longer need to drop targets from packages as we mark them as stable.
