This is the latest in the HEAD development of ruby-oci8. Reproducible: Always Steps to Reproduce:
Created attachment 218345 [details] ruby-oci8-2.0.3.ebuild Here is an e-build I used to build and test ruby-oci8-2.0.3. It configured, made, installed, and qmerged fine. After emerging, I was able to query an Oracle database fine.
Thanks for the update, we'll try to add it quickly. Just to be sure: is this backwards compatible, or do we need to take into account that the 1.x version should be installable at the same time?
Also, bonus points if you can convert this to use the new ruby-ng eclass. :-)
Created attachment 218699 [details] ruby-oci8-2.0.3.ebuild Okay, here's a stab at using ruby-ng.eclass. FWIW, it doesn't seem as convenient as the older ruby.eclass, but that's ok, I guess. I also made a couple changes. I realized that I didn't need this to depend on sqlplus, so I removed the dependency. The documents (especially NEWS) is quite informational for people who may want to use the latest features, so I added some dodocs for them, as well as an elog to inform people about it. ruby-oci8-2 development is backwards compatible and should stay in the same slot. It is currently the feature (trunk or head) branch, while the 1.x branch is currently the stable (bugfix only) branch. In fact, if we slotted it, we will have file collisions, as both versions cannot coexist (without some hacking). I've tested this ebuild several times, with a fresh install oracle-instantclient-basic install, sans sqlplus, and it works fine.
Created attachment 218701 [details] ruby-oci8-2.0.3.ebuild Ugh. I uploaded the wrong ebuild in the last update. This is the one I was talking about above. Sorry about that.
(In reply to comment #4) > Okay, here's a stab at using ruby-ng.eclass. FWIW, it doesn't seem as > convenient as the older ruby.eclass, but that's ok, I guess. Thanks, I've added this, with some minor changes, as ruby-oci8-2.0.3.ebuild. I've moved all the variables that are not strictly needed for the inherit ruby-ng below it, which is in keeping with the other ruby ebuilds. Also, I've moved the dodoc stuff into a separate all_ruby_install, since we only need to do this once even if there are multiple ruby installs. And I think the ruby team agrees: ruby-ng is a bit less convenient than the old eclass, but on the upside it does support multiple ruby implementations in a sane way which is especially good for dealing with gems.
