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 Steve, thank you for your reaction.
----- Original Message -----
From: "Steve Traylen" steve.traylen@cern.ch To: ruby-sig@lists.fedoraproject.org Sent: Wednesday, December 21, 2011 11:32:53 PM Subject: Prep, build and install
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.
Not really - the guidelines say, that you should use %prep for the gem install command (which basically unpacks the gem into a proper directory structure) and %install to place the files precisely where we need to under %{buildroot}.
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?)
I think that it wouldn't make much sense - the install command in %prep does everything we need - unpacks the gem into a proper directory structure (and compiles the binary extension, if any). This way you can use %prep to apply patches and then, if you need to recompile a patched C extension (if any), the %build section is the place to do it. Otherwise, I see no point in using %build section with rubygems.
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.
Yes, well, if you have nothing to compile, it makes perfect sense to leave the %build section empty, doesn't it? And you use %prep to unpack the gem and %install to place it into a proper directory structure. What's wrong with that? I think that it works exactly as it should.
Regards, Bohuslav.
-- Steve Traylen _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On 22 Dec 2011, at 07:32, "Bohuslav Kabrda" bkabrda@redhat.com wrote:
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.
Not really - the guidelines say, that you should use %prep for the gem install command (which basically unpacks the gem into a proper directory structure) and %install to place the files precisely where we need to under %{buildroot}.
Bohuslav,
Indeed you are correct, this has changed to some extent with this new draft where now not eveything is done in %install which is the case in the current guidelines.
But still the question of patching still arises, for the binary extension in the gem where would you patch it, surley the gem has to be unpacked as sepaerate step, its the only way you can get a patch in there.
Also when i was reviewing a ruby package i had to unpack myself so that i could check the contents of files for licensing. This is by hand then rather than the normall "rpmbuild -bp"
Fundamentally rpms have always unpacked to source before building and installing rather than just coverting package formats.
Ill be costructive and learn some more gem options to suggest something useful hopefully
Thanks,
Steve.
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?)
I think that it wouldn't make much sense - the install command in %prep does everything we need - unpacks the gem into a proper directory structure (and compiles the binary extension, if any). This way you can use %prep to apply patches and then, if you need to recompile a patched C extension (if any), the %build section is the place to do it. Otherwise, I see no point in using %build section with rubygems.
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.
Yes, well, if you have nothing to compile, it makes perfect sense to leave the %build section empty, doesn't it? And you use %prep to unpack the gem and %install to place it into a proper directory structure. What's wrong with that? I think that it works exactly as it should.
Regards, Bohuslav.
-- Steve Traylen _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Hi, Steve.
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.
Not really - the guidelines say, that you should use %prep for the gem install command (which basically unpacks the gem into a proper directory structure) and %install to place the files precisely where we need to under %{buildroot}.
Bohuslav,
Indeed you are correct, this has changed to some extent with this new draft where now not eveything is done in %install which is the case in the current guidelines.
But still the question of patching still arises, for the binary extension in the gem where would you patch it, surley the gem has to be unpacked as sepaerate step, its the only way you can get a patch in there.
As I mentioned in my previous mail, it is perfectly ok to use gem install in %prep, then patch the binary extension and use %build to recompile it. Otherwise, if it compiles ok, we have no problem, do we?
Also when i was reviewing a ruby package i had to unpack myself so that i could check the contents of files for licensing. This is by hand then rather than the normall "rpmbuild -bp"
Why? gem install basically untars the gem and in addition it generates the gemspec/rdoc.
Fundamentally rpms have always unpacked to source before building and installing rather than just coverting package formats.
Well, from one point of view, we _are_ just converting. And we conform with the standard packaging guidelines.
Ill be costructive and learn some more gem options to suggest something useful hopefully
As I see it, you have a problem with the fact, that gem install can compile the binary extension in %prep and not in %build, am I right? In this case, I really think it doesn't matter, but let some of the other guys state their opinions.
Bohuslav.
Thanks,
Steve.
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?)
I think that it wouldn't make much sense - the install command in %prep does everything we need - unpacks the gem into a proper directory structure (and compiles the binary extension, if any). This way you can use %prep to apply patches and then, if you need to recompile a patched C extension (if any), the %build section is the place to do it. Otherwise, I see no point in using %build section with rubygems.
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.
Yes, well, if you have nothing to compile, it makes perfect sense to leave the %build section empty, doesn't it? And you use %prep to unpack the gem and %install to place it into a proper directory structure. What's wrong with that? I think that it works exactly as it should.
Regards, Bohuslav.
-- Steve Traylen _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
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-...
On 12/22/2011 04:44 AM, Vít Ondruch wrote:
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.
Yes this is an interesting scenario, though I've never run into it myself (at least not as far as I recall).
It could also be the case that the gem compiles fine but the source needs to be patched anyways to remove some offending code, such as something not licensed under an acceptable license or other.
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.
We would need to run the 'gem install' command appending an "|| true" afterwards so as not to break the build process when gem install fails.
Why not just run "gem unpack %{SOURCE0}" here.
-Mo
Dne 22.12.2011 14:17, Mo Morsi napsal(a):
On 12/22/2011 04:44 AM, Vít Ondruch wrote:
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.
Yes this is an interesting scenario, though I've never run into it myself (at least not as far as I recall).
It could also be the case that the gem compiles fine but the source needs to be patched anyways to remove some offending code, such as something not licensed under an acceptable license or other.
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.
We would need to run the 'gem install' command appending an "|| true" afterwards so as not to break the build process when gem install fails.
Why not just run "gem unpack %{SOURCE0}" here.
Well, that is also option. However the "gem install" is standardized, therefore no need to think about it, you just need to add:
"|| true"
or
"|| :"
or may be
"| grep 'some specific failure description'"
which has the advantage of checking that error is different from what was expected (for example when gem is updated and bug fixed).
Also, I am not sure if unpack does not unpack something somehow differently.
BTW, I think that we should also introduce something like "gem_install" macro which would be used in place of the wordy "gem install" with parameters.
Vit
ruby-sig@lists.fedoraproject.org