Created attachment 318918 [details] rrdtool-bindings-1.4.7.ebuild Currently net-analyzer/rrdtool only builds bindings for ruby 1.8, and badly at that (bug 321607). I've had a look at improving this situation, but came to the conclusion that it will be much easier to support multiple ruby implementations with a separate package. I've added a proof-of-concept ebuild for the other implementations to my overlay, graaff, and attached here as well. My proposal would be to add these bindings as dev-ruby/rrdtool-bindings, providing support for all relevant ruby implementations in the tree. net-analyzer/rrdtool would then use --disable-ruby in econf() and PDEPEND on the bindings (depending on its ruby USE flag). I'm happy to make the changes if I get a sign-off from netmon.
As pva is inactive and i've taken maintainance over rrdtool, i'm ok with your idea. Please go on, also notice that rrdtool-1.4.7-r1 has just appeared.
Comment on attachment 318918 [details] rrdtool-bindings-1.4.7.ebuild This would match with an rrdtool ebuild change like this, I guess: --- rrdtool-1.4.8.ebuild 24 Mar 2014 14:29:15 -0000 1.10 +++ rrdtool-1.4.8.ebuild 27 Apr 2014 14:22:37 -0000 @@ -16,7 +16,7 @@ LICENSE="GPL-2" SLOT="0" KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 ~s390 ~sh ~sparc x86 ~x86-fbsd ~amd64-linux ~ia64-linux ~x86-linux ~x86-macos ~x86-solaris" -IUSE="dbi doc +graph lua perl python ruby rrdcgi static-libs tcl tcpd" +IUSE="dbi doc +graph lua perl python rrdcgi static-libs tcl tcpd" RDEPEND=" >=dev-libs/glib-2.28.7[static-libs(+)?] @@ -30,7 +30,6 @@ lua? ( dev-lang/lua[deprecated] ) perl? ( dev-lang/perl ) python? ( ${PYTHON_DEPS} ) - ruby? ( >=dev-lang/ruby-1.8.6_p287-r13 ) tcl? ( dev-lang/tcl ) tcpd? ( sys-apps/tcp-wrappers ) " @@ -95,12 +94,12 @@ $(use_enable perl) \ $(use_enable python) \ $(use_enable rrdcgi) \ - $(use_enable ruby ruby-site-install) \ - $(use_enable ruby) \ $(use_enable static-libs static) \ $(use_enable tcl) \ $(use_with tcl tcllib "${EPREFIX}"/usr/$(get_libdir)) \ --with-perl-options=INSTALLDIRS=vendor \ + --disable-ruby-site-install \ + --disable-ruby \ ${myconf[@]} } What is missing in the attached ebuild is a blocker on versions of rrdtool that install the same files.
(In reply to Jeroen Roovers from comment #2) > Comment on attachment 318918 [details] > rrdtool-bindings-1.4.7.ebuild > > This would match with an rrdtool ebuild change like this, I guess: I would propose to keep the ruby USE flag and make it pull in rrdtool-bindings. That way nothing changes for current users of rrdtool and people don't have to wonder where the ruby bindings went. > What is missing in the attached ebuild is a blocker on versions of rrdtool > that install the same files. We would only need the blocker on the old versions of rrdtool that still install the ruby bindings themselves, and vice-versa in rrdtool-bindings. The new rrdtool versions don't need any blocker, I think.
I have just added net-analyzer/rrdtool-1.4.8-r1 dev-ruby/rrdtool-bindings-1.4.8 to implement this. Please let me know if you spot anything weird or missing. Apologies for the large delay, I guess I must have missed Maxim's reply somehow.
(In reply to Hans de Graaff from comment #4) > I have just added > > net-analyzer/rrdtool-1.4.8-r1 It isn't there yet.
(In reply to Jeroen Roovers from comment #5) > (In reply to Hans de Graaff from comment #4) > > I have just added > > > > net-analyzer/rrdtool-1.4.8-r1 > > It isn't there yet. It seems I didn't actually commit it. It's there now, thanks.
I have readded USE=ruby for now since packages actually depend on net-analyzer/rrdtool[ruby] with an RDEPEND on dev-ruby/rrdtool-bindings. We may need to find and fix all the reverse dependencies or just leave it the way it is now. Unfortunately http://qa-reports.gentoo.org/output/genrdeps isn't populated at the moment so it's hard to check what needs ...[ruby] right now.
As I mentioned in comment 3 I think we should keep the "ruby" USE flag in any case, because we are doing something Gentoo-specific here in splitting off the bindings in a separate package. Without the USE flag they will be harder to find and there won't be any general documentation on it given that this is a Gentoo-specific solution.
Looks like it's fixed, then.
