Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 139348 - ruby.eclass -- please provide a conditional ruby dependence
Summary: ruby.eclass -- please provide a conditional ruby dependence
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Ruby Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 139322
  Show dependency tree
 
Reported: 2006-07-05 11:19 UTC by Emiliano Vavassori
Modified: 2006-07-07 07:15 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Emiliano Vavassori 2006-07-05 11:19:26 UTC
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.
Comment 1 Nick Devito 2006-07-05 11:21:25 UTC
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
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2006-07-05 11:45:09 UTC
Oh well... though, not sure if a separate bug was needed for this, pretty much covered by Bug 139322.
Comment 3 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-07-06 20:07:46 UTC
Asking an idea to portage devs.

Would this make sense, or you think that adding a ruby-functions eclass would be cleaner?
Comment 4 Zac Medico gentoo-dev 2006-07-06 20:22:24 UTC
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.
Comment 5 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-07-06 21:04:53 UTC
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?
Comment 6 Zac Medico gentoo-dev 2006-07-06 21:41:02 UTC
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. :)
Comment 7 Marius Mauch (RETIRED) gentoo-dev 2006-07-07 06:54:21 UTC
this shouldn't make a significant difference anyway (less than 1%).
Comment 8 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-07-07 07:09:29 UTC
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.
Comment 9 Emiliano Vavassori 2006-07-07 07:15:03 UTC
Thank you all.