If we can patch gem packages, it would be easier to handle a bunch of packages. We could unpack gem somewhere, patch it as usual and repack gem, something like this: src_unpack() { gems_unpack epatch blah blah gems_repack }
Created attachment 104130 [details, diff] gems.eclass patch This patch implements gems_unpack and gems_repack. This patch is however unlikely to work because of a bug in gem code (gem build metadata.yaml would fail). I'll se if I can patch gem for this
I'm not really fond of the idea to unpack and repack gems. Maybe it would better if we rebuild the gem from scratch. It seems most times, the non-gem distfiles include Rakefiles that support 'rake gem'. So then, we could do 'rake gem' during src_compile, and point GEMSRC at the newly built gem.
The appeal of using the gems is that they are low-maintenance and easy to install. I'm not sure it makes sense to repack the gem after patching if we are going to get the original source. Might as well install directly from that source code. Or am I overlooking why it would be beneficial to recreate the gem in this case.
When we package directly from gems, we're effectively using a blackbox. We don't have much control of what it installs, short of mucking around with unpacking, and repacking. When we regenerate the gem from source, we have full control over it. More specifically, we can patch it if necessary. We also would have more direct access to invoking unit tests, which can help us be more confident about version bumps, and help the arch teams with stabilization. We'd also still be using gems as the mechanism for installing to the file system, so their shouldn't be any associated hassle of using setup.rb. I don't think it would take much to add support for this to gems.eclass, such that gems would continue to be as easy to maintain/package.
I guess I'm not convinced upfront that trying to repackage the gems is going to be less work than mucking about with setup.rb for the purpose of installing the files in the filesystem. This just needs some experimenting with it to see if it is worth the hassle. So now someone needs to write the code. :-) Actually, this may be the only way to deal with packages that are only distributed as a gem (I'm not sure if there are any) so we may have to do something like this anyway.
Created attachment 141044 [details] gems-src.eclass Eclass for using rake to build gems, and then use gems.eclass to install.
Created attachment 141046 [details] activesupport-2.0.2-r1.ebuild Test ebuild which uses it
Created attachment 141048 [details, diff] files/activesupport-2.0.2-gem_platform.patch patch that it uses
We won't be fixing this for gems.eclass. Please use the new ruby-fakegem.eclass if you need to install a gem and also need to patch it. ruby-fakegem plays nice with all gentoo EAPI=2 phases and thus allows for easy patching.
