virtual/rubygems versions 6, 7, and 8 have the following as REQUIRED_USE, respectively: virtual/rubygems-6: REQUIRED_USE="|| ( ruby_targets_ruby20 )" virtual/rubygems-7: REQUIRED_USE="|| ( ruby_targets_ruby21 )" virtual/rubygems-8: REQUIRED_USE="|| ( ruby_targets_ruby22 )" If the flag is required unconditionally, then it doesn't make sense to have it in IUSE, in the first place.
It's not clear to me what the problem is here, apart from the issues already mentioned in bug 421497. Could you explain what is wrong here or which QA policy is violated?
Policy reference: http://devmanual.gentoo.org/general-concepts/use-flags/index.html "USE flags are to control optional dependencies and settings which the user may reasonably want to select." and "No combination of USE flags should cause a package to fail to build because users can set any combination of flags." There is nothing optional if there is only one possible setting of the flag. It should be omitted from IUSE, and the ebuild should just unconditionally depend on the respective ruby version.
This sounds like a good policy in general, but unfortunately is does not match what we do in the ruby-ng.eclass. There we use the RUBY_TARGETS USE_EXPAND mechanism to let ebuilds determine for which ruby implementations the package should be installed. Depending on what people set for RUBY_TARGETS and which ruby version they set with eselect it may not be possible to actually fulfill that request. Rather than failing obscurely somewhere during the build due to version mismatches we indicate this upfront by setting REQUIRED_USE. We still require IUSE as well because the ruby-ng.eclass dependency handling depends on that to pass on the set of required ruby targets for this package. All of this is handled by the ruby-ng.eclass and what you are seeing in virtual/rubygems is just the outcome of this when only one ruby target is specified. This isn't limited to this virtual, there are plenty of packages in the tree that (currently) only support one ruby target and thus have the same combination of REQUIRED_USE and IUSE. I agree that it looks a bit silly when you look at the generated outcome, but even when there are multiple ruby targets available having at least one matching one is mandatory. My suggestion would be that the policy should not apply in this case (and most likely the same it true for at least the new python eclasses, although I haven't checked in detail). If you still want to enforce this policy then I think we have the following options: 1) drop REQUIRED_USE: but in this case the ebuild itself will fail with obscure error messages once a versioning issue hits 2) change the logic of the eclass to silently install nothing when no matching RUBY_TARGETS are found: it seems to me that this will be a lot more confusing to users rather than telling them they are asking for an impossible combination 3) use a different mechanism to handle multiple ruby targets (e.g. a portage extension that handles them more like keywords), but that isn't available currently. I think option 1 just hides the problem and that it will lead to more bugs being filed and more users being confused. Option 2 is probably most in line with the policy, but I think this will also lead to confused users because we did something unexpected that was not their intention. Option 3 could be nice but it isn't here right now.
(In reply to Hans de Graaff from comment #3) > This sounds like a good policy in general, but unfortunately is does not > match what we do in the ruby-ng.eclass. There we use the RUBY_TARGETS > USE_EXPAND mechanism to let ebuilds determine for which ruby implementations > the package should be installed. Depending on what people set for > RUBY_TARGETS and which ruby version they set with eselect it may not be > possible to actually fulfill that request. > If an eclass design forces you to do weird things and not ahdere to QA standards and PMS, then there is room for improvement. > My suggestion would be that the policy should not apply in this case (and > most likely the same it true for at least the new python eclasses, although > I haven't checked in detail). If you still want to enforce this policy then > I think we have the following options: > It already breaks dependency resolving in some package managers, so I hope QA will not agree here. The fact that other eclasses may have this problem as well, is another reason to enforce this QA policy with more strictness. > 1) drop REQUIRED_USE: but in this case the ebuild itself will fail with > obscure error messages once a versioning issue hits > 2) change the logic of the eclass to silently install nothing when no > matching RUBY_TARGETS are found: it seems to me that this will be a lot more > confusing to users rather than telling them they are asking for an > impossible combination > 3) use a different mechanism to handle multiple ruby targets (e.g. a portage > extension that handles them more like keywords), but that isn't available > currently. > Such a portage extension would violate anything PMS stands for. Ebuilds and eclasses must not rely on unspecified portage behavior. In the other thread you said: > The problem we are trying to solve here is that if we used no slots and only > revisions or versions, then it would be much more of a pain to manage > stabilization and adding of new ruby providers, because each change would > introduce new versions. With the current solution we can simple manage one > slot per RUBY_TARGET. The solution looks pretty clear to me: you just have to go through the additional pain until a proper solution that satisfies both PMS and your needs is found.
If you all guys will look into distutils-r1 eclass you will found that similar non-obvious behaviour is there too. For example, let we have: PYTHON_COMPAT=( python2_7 ) then PYTHON_REQUIRED_USE which will be added to REQUIRED_USE during eclass parsing will be something like: REQUIRED_USE="|| ( python_targets_python2_7 )" And that's correct way, because, well - it is corner case, it can be installed for more than one version of Python. And you should not install python related package without any of python interpreter - it makes no sense for me. So, do we claim that python eclasses are suffer from the same problem? I think not.
(In reply to Julian Ospald (hasufell) from comment #4) > It already breaks dependency resolving in some package managers, so I hope > QA will not agree here. Can you explain me difference of that ebuilds and all those python-driven ebuilds that has only one implementation of python allowed? Cause, honestly, in terms of REQUIRED_USE expansion, i see no difference here.
(In reply to Sergey Popov from comment #6) > (In reply to Julian Ospald (hasufell) from comment #4) > > It already breaks dependency resolving in some package managers, so I hope > > QA will not agree here. > > Can you explain me difference of that ebuilds and all those python-driven > ebuilds that has only one implementation of python allowed? > > Cause, honestly, in terms of REQUIRED_USE expansion, i see no difference > here. I was commenting on the whole situation of virtual/rubygems which is not limited to REQUIRED_USE. The suggested fix in the other bug report (see also) however would make this bug obsolete.
Closing as a duplicate because bug 421497 has a wider scope. *** This bug has been marked as a duplicate of bug 421497 ***
As I tried to explain in comment 3 this bug is not related to bug 421497, other than that both issues are somewhat related to REQUIRED_USE and happen to occur in virtual/rubygems. @Julian: all your comments seem to be directed at the issue in bug 421497, not the issue addressed here. @Sergey: I agree that this issue also applies to python eclasses. Feel free to extend the subject of the bug even further. My view on this issue is that we should amend the policy for these cases since I believe that our current approach results in the best user experience.
(In reply to Hans de Graaff from comment #9) > @Sergey: I agree that this issue also applies to python eclasses. Feel free > to extend the subject of the bug even further. Well, the problem is if we drop REQUIRED_USE from such packages we can end with situation that user have installed virtual(rubygems for example) with NO selected Ruby implementation, thus - no actual package will be pulled in. So, i'd prefer to keep things in order for now. Python eclass use REQUIRED_USE="|| ( all_implementation_of_python_selected )", ruby eclasses do this too. And i do not think that it should be changed. The only culprit here as i see - users, trying to install something with USE="-*". But that's not very common case, and systems, that have USE="-*" in make.conf are mostly broken, unless there are other options redefined in package.use. So, this bug seems fixed to me after introducing virtual/rubygems-10 Let's concentrate on fixing bug #421497, cause this is the real problem - after it will be fixed - we will be good. This bug is only consequence of bug #421497, no more, no less...
You could argue it's a bug in PMS. PMS allows both || ( foo ) and even worse || ( )
(In reply to Julian Ospald (hasufell) from comment #11) > You could argue it's a bug in PMS. > > PMS allows both > > || ( foo ) Why would this be a bug? It is useful to allow this for eclass generated dependencies. > and even worse > || ( ) Yes, this one is debatable. Especially that it evaluates to true.
(In reply to Julian Ospald (hasufell) from comment #11) > You could argue it's a bug in PMS. > > PMS allows both > > || ( foo ) That's non-obvious, but looks legit in my point of view > and even worse > || ( ) This expressions makes no sense and should be banned by PMS
(In reply to Ulrich Müller from comment #12) > (In reply to Julian Ospald (hasufell) from comment #11) > > You could argue it's a bug in PMS. > > > > PMS allows both > > > > || ( foo ) > > Why would this be a bug? It is useful to allow this for eclass generated > dependencies. > Then I don't understand why you complain about REQUIRED_USE="|| ( ruby_targets_ruby20 )" Whether "ruby_targets_ruby20" is plaintext or behind an arbitrary variable doesn't make a practical difference. In addition, fixing e.g. PYTHON_REQUIRED_USE="|| ( ${flags[*]} )" to not end up in "|| ( foo )" syntax would be a triviality.
(In reply to Sergey Popov from comment #10) > Let's concentrate on fixing bug #421497, cause this is the real problem - > after it will be fixed - we will be good. This bug is only consequence of > bug #421497, no more, no less... No, it's not (a consequence). Any package that has only a single ruby target will have this issue. See e.g. those currently listed on https://wiki.gentoo.org/wiki/Project:Ruby/Ruby_1.9_deprecation all of which currently have USE_RUBY="ruby19". In any case I think the status quo is fine, so I'm not going to reopen this bug.
