Dne 21.12.2011 23:32, Steve Traylen napsal(a):
Hi,
I noticed the link to the new ruby packaging draft and had a comment.
Currently the guidelines suggest to do everything basically within prep with build and install empty.
Can it be considered to break this up into the prep build and install sections. The gem can unpacked in prep and im hoping its possible to build and then install from that unpack...( i dont know how to do this or if is possiblE?)
In the current situation it is not obvious how you would apply a patch in the rpm and probably more importly the "rpmbuild -bp", "rpmbuild -bc" or "rpmbuild -bi" do not have there normal meaning.
Hi Steven,
I'll try to elaborate a bit about this. So the common way how to install the gem is to use command "gem install". The advantage and sometimes disadvantage is that the gem install is doing everything in one step. So where you would use 3 steps (%prep, %build, %install) in RPM, the gem is doing in once. This arises question where to call this command in RPM spec. The current guidelines says that %prep and %build sections should stay empty. This works just fine for large amount of gems, lets say 80% of cases.
However, there is other situation, where you need to patch either the .gemspec file or the Ruby code. This can be seen for example in Rails packages quite often. Rails specifies dependency on some gem version, however, in Fedora, there is just older version, so the .gemspec has to be patched accordingly. Therefore in such packages, the "gem install" is called already in prep section as well as patching is done. Then, in %install section, the gem is copied into the final destination in %{buildroot}. This approach is necessary lets say for 18% of gems.
We decided, that this has its benefits and it is covered now in the guidelines draft. Among others, this allows you to use the "rpmbuild -bp" and "rpmbuild -bi" with regular meaning, e.g. you can use "rpmbuild -bp" when you want to check the license for example. However, as you may noticed, the "rpmbuild -bc" has still no meaning and the %build section is empty.
And now we have the remaining 2% of gems, which have binary extensions, which unfortunately don't build and needs to be patched. This situation is not covered by the guidelines, but you are right that we should work that out, because this is unfortunate situation for both, package and reviewer. I have met already such situation and I opened the support ticket for this scenario [1], however no reasonable solution were provided.
I think we should do following steps for such case:
%prep a) Do regular "gem install" in prep section. It is obvious that the gem installation fails, however the gem itself is unpacked in the correct locations. b) Apply your patches c) Generate the .gemspec using "gem spec" command (not sure if it is really doable, but it should be according to [1]). d) Generate the documentation.
%build a) Go into ext directory and execute "ruby extconf.rb" b) Build the extension
%install As always, move the gem into final destination.
This is how I believe it could work. However, I have never did that before. Do you have some particular gem which needs to be treated like that? If I could remember why I asked the [1] .....
Vit
[1] http://help.rubygems.org/discussions/problems/584-how-to-install-binary-gem-...