Bug 180066

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