From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20060202 Fedora/1.0.7-1.2.fc4 Firefox/1.0.7 Description of problem: I have put together an template file for ruby packages for the fedora-newrpmspec command. If you like it, you can integrate it in a future release. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. not applicable 2. 3. Additional info:
Created attachment 124199 [details] Ruby template for fedora-newrpmspec
I think this is a good idea, but the implementation is not quite ready. In particular: - Too many comments for a spec template at the top of the specfile near the %defines as well as the License tag. - Requires: ruby = %(...) needs verification whether it does the right thing. Maybe something like python(abi) and perl(:MODULE_COMPAT_*) should be implemented in the ruby(-libs?) package. Additionally, do all ruby extension packages require ruby, or would ruby-libs be more appropriate? - BuildRequires: ruby is needed, because ruby-devel does not pull in ruby (only ruby-libs) and ruby is invoked in the above Requires: ... line - Should use %{ruby_sitelib} and %{ruby_sitearch} for consistency with perl and python - The current %{ruby_sitedir} definition actually defines %{ruby_sitearch} - Is there a generic thingy that ruby extensions use akin to perl's "perl Makefile.PL ; ..." and python's "python setup.py ..."? Help from people who are familiar with ruby packaging would be appreciated.
One more thing: if ruby extensions generally include a test suite (and maybe even if not), %check section should be added.
(In reply to comment #2) > I think this is a good idea, but the implementation is not quite ready. In > particular: > > - Too many comments for a spec template at the top of the specfile near the > %defines as well as the License tag. Well, I agree with you, but concerning the License tag I like to put some kind of comment into the file to clarify the license issue. Or do you suggest to correct this in case someone commits a new package? > - Requires: ruby = %(...) needs verification whether it does the right thing. > Maybe something like python(abi) and perl(:MODULE_COMPAT_*) should be > implemented in the ruby(-libs?) package. Additionally, do all ruby extension > packages require ruby, or would ruby-libs be more appropriate? Basically you could provide a ruby extension, that only requires the ruby package, but you mentioned the right thing. ruby-libs is what I shall require in the template, especially cause the directories from the macros are provided by ruby-libs. I am not sure what the reasoning behind this python-abi = %(...) is, but what I need to check is, that ruby is >= 1.8 cause there are syntactic differences between ruby 1.6 and ruby 1.8. But this is the only thing I have to check. How would you implement this? > - BuildRequires: ruby is needed, because ruby-devel does not pull in ruby > (only ruby-libs) and ruby is invoked in the above Requires: ... line Fixed. And most of the time you also need ruby to execute some kind of install script. > - Should use %{ruby_sitelib} and %{ruby_sitearch} for consistency with perl > and python Fixed. > - The current %{ruby_sitedir} definition actually defines %{ruby_sitearch} Fixed. > - Is there a generic thingy that ruby extensions use akin to perl's "perl > Makefile.PL ; ..." and python's "python setup.py ..."? Sadly not yet. I have two packages submitted so far, and both use different approaches. But these things are clarifying in the future. A lot developers are moving to Gems, which is ruby's CPAN equivalent. > Help from people who are familiar with ruby packaging would be appreciated.
(In reply to comment #3) > One more thing: if ruby extensions generally include a test suite (and maybe > even if not), %check section should be added. Fixed. Not all packages include a test suite, so I put an empty %check section inside the template.
Created attachment 124206 [details] Updated version
Created attachment 124207 [details] really updated version
(In reply to comment #4) > Well, I agree with you, but concerning the License tag I like to put some kind > of comment into the file to clarify the license issue. Or do you suggest to > correct this in case someone commits a new package? I don't think there's any need for clarification/correction. > I am not sure what the reasoning behind this python-abi = %(...) is, but what > I need to check is, that ruby is >= 1.8 Actually, if it's like in perl/python, one needs to require a version of ruby-libs that the package works with, including ruby-libs loading extensions from the versioned install dirs. >= 1.8 is probably incorrect, because I guess ruby 2.0 won't load extensions from the 1.8 dirs. The ruby-libs package could provide for example ruby(abi) = 1.8, and in that case the scriptlet from your original specfile would be ok I think (obviously changed to require ruby(abi) = ...). Currently, I think the best that can be done is to use dir based dependencies, %{ruby_sitelib} for noarch, %{ruby_sitearch} for non-noarch. I've committed the template from comment 7 to CVS with the dir based deps and other minor modifications, please submit further changes as diffs against the fedora-rpmdevtools in the fedora (note: not extras) repository, http://cvs.fedora.redhat.com/viewcvs/fedora-rpmdevtools/?root=fedora I wonder if a 'export CFLAGS="$RPM_OPT_FLAGS"' should be put to the spec template's %build section (to honor $RPM_OPT_FLAGS like in perl/python). Also, is it possible to include something better than the comments in %files, for example stuff like in the perl spec template?
Created attachment 124214 [details] Diff including the changes to %files and %build section I applied and tested your suggested changes on some of my packages and they work fine.
Applied, thanks.
Included in 1.5-1.
Reopening due to recent multilib related discussions/concerns on fedora-extras list. Whoever knows the status of ruby packaging in FC/FE, please let me know if the spec template could be fixed so it'd be working properly now, or if it should be just dropped from fedora-rpmdevtools for now until the rest of the ruby infrastructure in FC is ready.
The multilib issue is being tracked as bz184199; not much progress has been made on actually fixing it so far.
Ok, thanks. Unless a solution is available by the time the next fedora-rpmdevtools release is due (for which I have currently no hurry for), I'll disable the ruby template.
Created attachment 131972 [details] Updated ruby spectemplate All outstanding ruby packaging issues have been resolved; this file is an updated version of the ruby spectemplate and takes all the guidleines described at http://www.fedoraproject.org/wiki/Packaging/Ruby into consideration (or so I hope)
There's a spurious "BuildArchitectures: noarch" line in the new template, I suppose there are no objections to removing that. A BuildArch: placeholder is already there. I see ruby_sitelib and ruby_sitearch have had "dir" appended to them. While cosmetic, I think it would be good to be consistent with the perl and python precedents in templates and/or macros shipping in the main rpm package; both of perl and python use *_sitelib and *_sitearch without the trailing "dir". I've committed to rpmdevtools CVS with those changes, let me know if there are strong opinions on the *_site*dir macro names and/or if they're "set in stone" and I'll add those changes too. http://cvs.fedora.redhat.com/viewcvs/fedora-rpmdevtools/spectemplate-ruby.spec?root=fedora&rev=.&view=markup
Thanks for fixing the BuildArch thing With the names of the *_site* macros, I tried to stay consistent with the entries in Config::CONFIG that get read out, but I am fine with dropping the *dir and making it look like perl/python. I'll update the packaging guidelines to use those shorter names, too.
The updated version is shipped in rpmdevtools 5.0-2