Hello, Inheriting ruby.eclass for using its functions may not unconditionally add a dependence on ruby (virtual/ruby). We've at least one problem (bug 139322) regarding the unconditional dependence on ruby when ruby.eclass is inherited. For more information, please see the bug report mentioned above. An idea (as reported by Jakub Moc) is to add: if [[ ${RUBY_OPTIONAL} != "yes" ]] ; then DEPEND="${DEPEND} virtual/ruby" else DEPEND="${DEPEND} ruby? ( virtual/ruby )" fi to ruby.eclass. Thank you all.
We could also do something similar as to the python eclass: if [[ -n "${NEED_PYTHON}" ]] ; then DEPEND=">=dev-lang/python-${NEED_PYTHON}" RDEPEND="${DEPEND}" fi
Oh well... though, not sure if a separate bug was needed for this, pretty much covered by Bug 139322.
Asking an idea to portage devs. Would this make sense, or you think that adding a ruby-functions eclass would be cleaner?
You wouldn't really want to have too many conditionals like that, but if it's just one then it's not so bad. It just allows ebuilds that don't necessarily need ruby to turn that off, while all the other ebuilds that need it get it implicitely.
What I'm wondering is the long term result in overhead during metadata generation. What would be the difference respect a ruby-functions eclass (inherited by ruby)? slower/faster?
metadata generation performance really shouldn't be a consideration in these types of decisions. The current method used to generate metadata is quite inefficient and will certainly be improved (pkgcore is highly optimized for this). When you inherit ruby.eclass, you also incur the overhead of sourcing eutils and toolchain-funcs, but you shouldn't worry too much about that (hopefully you're not generating metadata on a 386). The decision the you make should be more about coding style. The simplest solution is often (but not always) the best. :)
this shouldn't make a significant difference anyway (less than 1%).
Done, now RUBY_OPTIONAL="yes" disable the dependency on virtual/ruby. WARNING WARNING WARNING WARNING WARNING WARNING As we can't predict the behaviour of all ebuilds when ruby is optional, as in which flag and when and so on, IUSE and DEPEND _have_ to be set by the ebuild itself.
Thank you all.