[Fedora-packaging] rubygem with extension written in C

[David Lutterkort]

On Tue, 2008-11-04 at 19:46 +0900, Mamoru Tasaka wrote:
> Thank you for reply.
> 
> David Lutterkort wrote, at 11/04/2008 04:04 AM +9:00:
>  
> > First off, I think this is a very good step in the right direction. A
> > couple of questions:
> > 
> >       * Is the example snippet from a spec file meant only for gems with
> >         extension libraries or for all gems ?
> 
> - Currently only with extention libraries.
>   If rpm created from gem file is completely noarch, gem file can be installed
>   under %{buildroot}%{gemdir} directly.
>   (However, of course, there is no problem if we first install gem files
>    under %{_builddir} first even if it is noarch)

Agreed. Ultimately, it would be nice to support more of this with some
stock macros; but that has nothing to do with your proposal.

> >       * Do you have a full example somewhere that follows your
> >         recommendations ?
> 
> - I tried to rewrite spec files in Fedora related to rubygem, which I put
>   under
>   http://mtasaka.fedorapeople.org/rubygem_specs/
>   The easiest example is
>   http://mtasaka.fedorapeople.org/rubygem_specs/rubygem-fastthread.spec

Nice, just tried it and it does produce a -debuginfo, complete with
sources :)

> >       * As for missing files in ext/, I would be happy either way; since
> >         the C sources for extensions are usually very small, it would be
> >         ok to install them as part of the rubygem- package. OTOH, I
> >         don't see much danger in leaving them out from the rubygem. The
> >         main point of building a rubygem- RPM is so that users can
> >         satisfy rubygem-level dependencies for other rubygems with the
> >         RPM-installed rubygem, i.e. if gem A is packaged as an rpm, and
> >         a user wants to 'gem install B' where B has a gem-level dep on
> >         A, that should still work. Users shouldn't expect that a 'gem
> >         uninstall A' would work - it would confuse RPM, anyway.
> 
> - Thanks. I added some guideline proposal about files under ext/ C codes with
>   reflecting your commends.

The proposal looks really good - +1 from me.

David