Hi, For a long time I was wondering why there is no ruby.eclass even though there are more than 50 ebuilds in Portage tree. However, I didn't take any action about it until ruby-1.6.8 was going to be removed (or, at least, not supported) and in fact it turned out to be some ebuilds become broken with the change. So I created ruby.eclass today just for starting point. It will eventually support both ruby-1.6.8 and ruby-1.8.x but at the moment it will do almost the same thing as ruby-gnome2.eclass does (I found it yesterday ;-p). I suggest ruby.eclass because it is not intended only to modules or libraries but also to applications with ruby.
Created attachment 16520 [details] ruby.eclass
Hi, I just searched for a method to get the ruby lib path in gentoo. I found ruby -r rbconfig -e 'print Config::CONFIG["sitelibdir"]' in your eclass and in some ebuilds. The output is /usr/lib/ruby/site_ruby/1.6 but this path doesn't exist on my machine. The desired output should be /usr/lib/ruby/1.6. I have ruby-1.6.8-r1 installed. I think this enhancement/bug should get a higher priority, as it affects a other ebuilds, too.
CONFIG["rubylibdir"] --> /usr/lib/ruby/1.6
It is installed on my system (I'm using ruby-1.6.8-r1 as well). rico% qpkg -l ruby-1.6.8-r1 | grep site /usr/lib/ruby/site_ruby /usr/lib/ruby/site_ruby/1.6 /usr/lib/ruby/site_ruby/1.6/i686-linux Please add your output of `qpkg -l ruby-1.6.8-r1` if `qpkg -l ruby-1.6.8-r1 | grep site` doesn't return site_ruby dir.
That's odd: `qpkg -l ruby-1.6.8-r1 | grep site` returns >/usr/lib/ruby/site_ruby >/usr/lib/ruby/site_ruby/1.6 >/usr/lib/ruby/site_ruby/1.6/i686-linux-gnu but /usr/lib/ruby/site_ruby does not exist (?!?) I'm really sure, that I never deleted anything below /usr/lib by hand. I'll reemerge ruby to see what happens.
I reemerged it. The ruby ebuild definitely creates /usr/lib/ruby/1.6/i686-linux-gnu, but not /usr/lib/ruby/site_ruby/1.6/i686-linux-gnu
That sounds very weird. From my log of ruby's installation, it says as following: ... >>> Install ruby-1.6.8-r1 into /var/tmp/portage/ruby-1.6.8-r1/image/ category dev-lang ./miniruby ./instruby.rb /var/tmp/portage/ruby-1.6.8-r1/image/ mkdir /var/tmp/portage/ruby-1.6.8-r1/image//usr/bin ruby -> /var/tmp/portage/ruby-1.6.8-r1/image//usr/bin/ruby chmod 0755 /var/tmp/portage/ruby-1.6.8-r1/image//usr/bin/ruby mkdir /var/tmp/portage/ruby-1.6.8-r1/image//usr/lib libruby.so.1.6.8 -> /var/tmp/portage/ruby-1.6.8-r1/image//usr/lib/libruby.so.1.6.8 chmod 0555 /var/tmp/portage/ruby-1.6.8-r1/image//usr/lib/libruby.so.1.6.8 mkdir /var/tmp/portage/ruby-1.6.8-r1/image//usr/lib/ruby/1.6 mkdir /var/tmp/portage/ruby-1.6.8-r1/image//usr/lib/ruby/1.6/i686-linux mkdir /var/tmp/portage/ruby-1.6.8-r1/image//usr/lib/ruby/site_ruby/1.6 mkdir /var/tmp/portage/ruby-1.6.8-r1/image//usr/lib/ruby/site_ruby/1.6/i686-linux link libruby.so.1.6.8 -> libruby.so.1.6 link libruby.so.1.6.8 -> libruby.so ... and consequently /usr/lib/ruby/site_ruby/1.6 was created on my system. How does your log say about it?
Uhh, nasty - found the problem. Portage creates the directories and tells you that it installs them, but if you don't use the keepdir function from ebuild.sh, it autocleans the empty directories. I think Portage could handle this a bit smarter. Adding keepdir `ruby -r rbconfig -e 'print Config::CONFIG["sitearchdir"]'` after make install in the ruby ebuild fixes this problem. I suppose you have "noclean noauto" in make.conf features, so you did not get aware of this!?
I don't think noauto and noclean keeps that directories (since I don't set them and I set AUTOCLEAN=yes). I re-emerged ruby-1.6.8-r1 twice, first with portage 2.0.49 and second with 2.0.48-r5, and /usr/lib/ruby/site_ruby was created both time. I don't know why.... Adding keepdir to ruby ebuild is a good thing (it doesn't harm anything) because at least you encounter the problem ;-)
From http://www.gentoo.org/doc/en/gentoo-howto.xml >keepdir Creates (if necessary) a .keep file in the given directory so that it isn't auto-cleaned. I would really like to know, why it doesn't clean the directories on your machine, though this should be the behaviour, you have to expect.
Hi, I tested re-emerging ruby-1.6.8-r1 on different machines, and got the same result. Alpha, PPC and SPARC boxes got /usr/lib/ruby/site_ruby/1.6/{alpha,powerpc,sparc}-linux created respectively. What I did is `emerge -C ruby [and all ruby-ebuilds]` and `emerge '=ruby-1.6.8-r1'`. emerging without unmerge of ruby causes Portage to delete empty dirs that are shared with two versions of ruby (in other words, if you didn't `emerge -C ruby` empty dirs would be removed). You can have a look at the "problem" by querying bugzilla by "empty dir".
Thanks for clarification. I have to say, that I'm a bit annoyed about the amount of bugs regarding portage. I hoped portage would mature faster. :-(
Mamoru - Thanks, this is a good idea. Working on putting it into the tree right now. Carlo - I added the keepdir fix to ruby-1.6.8-r1.ebuild and ruby-1.8.0.ebuild. Thanks for tracking that down.
Mamoru - I added this to cvs with some minor changes. Since you're a Gentoo dev, how about you take over from here? I didn't realize at first that you're a dev!
Well, I made a couple more changes to ruby.eclass and used it for rdtool, so I'll reassign this bug to myself and close it.
Thanks. I'll use it and commit several ebuilds after you close this bug ;-) Before that, let me ask you a question. Can I resurrect ruby ebuilds that depend on <dev-lang/ruby-1.8 ? I think it's too early to break ruby-1.6.x dependency (such as optparse). If anything happens I'll modify ruby.eclass and try to deal with it (if it is appropriate). When there will be a number of ebuilds which only work under >=ruby-1.8 and only a few people use ruby 1.6.x (cf. Emacs 19), that'll be the time to erase those ebuilds depending on <ruby-1.6.
I'm glad that I could help to fix this. Originally I only wanted to get the ruby archdir for another ebuild, because configure couldn't find the include path. It would be not bad, if the ruby.eclass would export it.
Mamoru, I think you're right that we shouldn't be breaking 1.6.8 compatibility at this point. The optparse ebuild was removed prematurely. It sounds like you're interested in contributing more to the dev-ruby area and firming up all things ruby. Please feel free to add yourself to the list of maintainers for the herd and dive in. On the subject of 1.8.0, it's definitely in our best interest to move everything in that direction as soon as possible, so if you have cycles to spare, I'd suggest spending time working on that rather than resurrecting too much in the way of 1.6.8. It's usually not hard to make applications work with 1.8.0 and we can feed the patches upstream as we come up with them. For example, I did some of the work to make vim work with ruby 1.8.0. Okay, I'll close this bug now and we can handle more ruby problems in new bug reports.
