Bug 180066 - Request: Inclusion of a ruby template file
Request: Inclusion of a ruby template file
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: fedora-rpmdevtools (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
Depends On: 184199
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-05 05:45 EST by Oliver Andrich
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 5.0-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-22 16:06:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Ruby template for fedora-newrpmspec (1.28 KB, application/octet-stream)
2006-02-05 05:46 EST, Oliver Andrich
no flags Details
Updated version (807 bytes, application/octet-stream)
2006-02-05 07:40 EST, Oliver Andrich
no flags Details
really updated version (815 bytes, application/octet-stream)
2006-02-05 07:42 EST, Oliver Andrich
no flags Details
Diff including the changes to %files and %build section (663 bytes, patch)
2006-02-05 11:35 EST, Oliver Andrich
no flags Details | Diff
Updated ruby spectemplate (1.13 KB, text/plain)
2006-07-05 20:25 EDT, David Lutterkort
no flags Details

  None (edit)
Description Oliver Andrich 2006-02-05 05:45:54 EST
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:
Comment 1 Oliver Andrich 2006-02-05 05:46:56 EST
Created attachment 124199 [details]
Ruby template for fedora-newrpmspec
Comment 2 Ville Skyttä 2006-02-05 06:28:04 EST
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.
Comment 3 Ville Skyttä 2006-02-05 06:30:15 EST
One more thing: if ruby extensions generally include a test suite (and maybe
even if not), %check section should be added.
Comment 4 Oliver Andrich 2006-02-05 07:38:08 EST
(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.


Comment 5 Oliver Andrich 2006-02-05 07:39:09 EST
(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.
Comment 6 Oliver Andrich 2006-02-05 07:40:04 EST
Created attachment 124206 [details]
Updated version
Comment 7 Oliver Andrich 2006-02-05 07:42:33 EST
Created attachment 124207 [details]
really updated version
Comment 8 Ville Skyttä 2006-02-05 09:01:51 EST
(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?
Comment 9 Oliver Andrich 2006-02-05 11:35:12 EST
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.
Comment 10 Ville Skyttä 2006-02-05 13:20:54 EST
Applied, thanks.
Comment 11 Ville Skyttä 2006-02-26 12:43:45 EST
Included in 1.5-1.
Comment 12 Ville Skyttä 2006-04-02 18:06:59 EDT
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.
Comment 13 David Lutterkort 2006-04-03 14:50:30 EDT
The multilib issue is being tracked as bz184199; not much progress has been made
on actually fixing it so far.
Comment 14 Ville Skyttä 2006-04-03 16:05:43 EDT
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.
Comment 15 David Lutterkort 2006-07-05 20:25:43 EDT
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)
Comment 16 Ville Skyttä 2006-07-06 17:51:36 EDT
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
Comment 17 David Lutterkort 2006-07-07 17:59:17 EDT
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.
Comment 18 Ville Skyttä 2006-08-22 16:06:56 EDT
The updated version is shipped in rpmdevtools 5.0-2

Note You need to log in before you can comment on or make changes to this bug.