As I said before, I’m doing a lot of work to port Ruby packages in Gentoo to the new eclasses so that the gems can integrate better with Portage. Integrating better in this case means respecting the build phases we have in ebuilds (unpack, prepare, compile, test, install, merge to live filesystem), respecting the dependency tree as provided by Gentoo (including split dependencies for Ruby 1.8, 1.9 and JRuby) and the doc USE flag to build or not the API documentation.
Unfortunately, this is not really such an easy task sometimes, for at least two main reasons. The first is the lack of ebuilds for the packages needed for the tests to work; the second is the lack of proper dependency information in gems.
Missing ebuilds are due to the fact that, earlier, we never ran tests so we never had the need for some of the test-specific dependencies. At the same time we never cared much about documentation, so also the dependencies needed for documentation building were never worked on. There is quite a cross-over between the two of these classes of dependencies, and those are the dependencies for the Rakefile directly (both tests and documentation generation are handled by rake for most packages).
The other problem is that the gems themselves, while having a syntax to provide the dependency information (also split between runtime and development dependencies, the equivalent of our RDEPEND and DEPEND), they are rarely complete, at least for what concerns development dependencies (which is what we care about for documentation and, even more importantly, tests). Without this kind of information, making sure that tests work is often a matter of try-and-see: you run the tests and add the dependencies if they are not installed.
Unfortunately while usually adding a new ebuild does not lead to extreme trouble, Ruby gems make it quite a hassle, especially for the problems mentioned above. You cannot rely on the specification-provided information, since as I said is often incomplete. And at the same time, the sheer amount of packages that are possibly used for tests is definitely high (there are some different documentation tools as well but not near as many), which sometimes mean that to fix the tests for one single package, you end up having to package about a dozen, sometimes with interleaved, looping dependencies.
Now, the reason why I’m blogging about this right now s that I have to ask you, the users, to help me out with this. Please try to run tests on the Ruby ebuilds, and report if the any dependency is missing. Having now dozens of installed Ruby gems, both via fakegem and the old-style ebuilds, I don’t “feel” the dependencies as much; while I do tend to check the require directives, they often are confused enough that I might not notice entirely.
So pretty please, help me help you, and check for missing dependencies together ith me and the rest of the developers, thanks!
I’m making a virtualbox machine that emerges ruby packages on a blank stage3 system (formatting the drive after each package). When a dependancy fails it shows up in the logs.
I’m hitting circular dependancies all over the place and i’m not even using ~x86have you had this before with ruby packages?
Yes, unfortunately it is known that enabling the doc or test USE flags cause an impossible amount of cyclic (if not outright circular) dependencies. Either me or Hans will likely draw a graph of some of those dependencies one day, it’d be fun, especially for stuff like “unbundled Rails” (where you don’t use the vendor-copies of gems but rather depend on the proper projects), as it brings in all kind of fun dependencies. And that would give a sense of why it’s taking us so long to do the porting to the new eclasses.
Not sure if this is the kind of dependency problem you’re taking about, but Sinatra is refusing to install on my system with the complaint:emerge: there are no ebuilds built with USE flags to satisfy “>=dev-ruby/rack-0.9.1[ruby_targets_ruby18]”.Which is very odd, because I do indeed have rack installed (1.0.1).Any suggestions as to where to start hunting for the cause?(AMD64 default profile, if that’s of any interest)
John, make sure you don’t have any ebuilds in overlays that might collide with the main system. Those will most likely not be ported to our new system at all.Also note that only 1.0.1-r1 is moved to ruby-fakegem so you need the ~arch version of it.