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-g...