Currently ruby-ng.eclass dies if a ruby target is not met with this message for all EAPIs: You need to select at least one Ruby implementation by setting RUBY_TARGETS in /etc/make.conf. I propose for EAPI 4 that the ruby-ng.eclass add all the ruby targets to REQUIRED_USE if RUBY_OPTIONAL is "no". This will prevent the package from even attempting to merge since the ebuild already knows that it won't be possible. This is especially handy for an ebuild that would attempt to use only ruby19 like this: USE_RUBY="ruby19" RUBY_OPTIONAL="no". If the user does not unmask the ruby_targets_ruby19 use flag, the package will still show whatever dependencies it's going to merge and attempt to merge anyway when this is not possible. This change should alert the user to the situation without causing a merge to die and may even prevent bogus bugs from being filed. Reproducible: Always
Created attachment 278379 [details, diff] ruby-ng.eclass.patch Proposed ruby-ng.eclass patch. This adds two functions: ruby_get_use_implementations: This will get an array of implementations that the user enabled through RUBY_TARGETS. This is technically out of the scope of this bug but I need it for an ebuild I'm working on. ruby_get_use_targets: This gets an array of ruby_targets_[implementation] to be used with the REQUIRED_USE portion below it
Created attachment 278387 [details, diff] ruby-ng.eclass.patch Removed the prepended REQUIRED_USE which is not allowed.
The ruby_get_use_implementations is needed because there aren't any functions that provide an array of implementations that are enabled by the user. A good example of this is the librets ebuild I am working on in the sunrise overlay. I cannot use a lot of the built-in functions provided by ruby-ng because the package optionally depends on ruby and does not build in the typical manner a ruby package is built (it uses swig). I need get a list of the implementations enabled by the user so I can determine which implementations to compile against manually. This function would make my ebuild a little simpler and possibly provide for other cases where there are unorthodox builds for packages that support ruby.
Thanks Matthew, you're right of course on the approach, looks good to me as well.
I've just added both patches to ruby-ng. (Both? Yes, I split the patch into both functional components to avoid future headscratching.) Thanks!
