[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debigem: .gem -> debian source automatically



On Sep 26, 2010, at 3:24 PM, Antonio Terceiro wrote:

> Hi Clint,
> 

Hi Antonio!

> I tried it here on a Debian unstable machine and the package build
> failed:
> 

Thanks for giving it a spin..
<snip>

> 
>  make[1]: Entrando no diretório `/home/terceiro/src/debigem/test/libfast-gettext-ruby-0.5.10'
>  dh_rubygems build
>  ERROR:  While executing gem ... (NameError)
>      uninitialized constant Gem::Specification::YAML

This is caused by this bug in rubygems 1.3.7:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597554
http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=28582

To work around it, do:
touch ~/.gemrc

>  /usr/bin/dh_rubygems:113:in `build_gemspec': gem build failed for debian/libfast-gettext-ruby.gemspec (RuntimeError)
>    from /usr/bin/dh_rubygems:254
>    from /usr/bin/dh_rubygems:92:in `for_each_package'
>    from /usr/bin/dh_rubygems:84:in `each'
>    from /usr/bin/dh_rubygems:84:in `for_each_package'
>    from /usr/bin/dh_rubygems:83:in `each_pair'
>    from /usr/bin/dh_rubygems:83:in `for_each_package'
>    from /usr/bin/dh_rubygems:254
>  make[1]: ** [override_dh_auto_build] Erro 1
>  make[1]: Saindo do diretório `/home/terceiro/src/debigem/test/libfast-gettext-ruby-0.5.10'
>  make: ** [build] Erro 2
>  dpkg-buildpackage: error: debian/rules build gave error exit status 2
>  debuild: fatal error at line 1327:
>  dpkg-buildpackage -rfakeroot -D -us -uc failed
> 
> That's weird, because I didn't find any reference to "YAML" in debigem's source
> code.

Yeah, its rubygems problem unfortunately. I developed using 1.3.6.

> 
> That's great work you did.
> 

Thanks! I really appreciate the feedback.

> I'm not sure, though, whether it's a good thing or bad thing to have
> rubygems as a build dependency for all Ruby packages on Debian ...
> 

I'm not entirely sure it is a good thing either. My main reason for
choosing that path is that the ruby developers know what to expect
from 'gem install', so I see a lot of value in staying close to
what the author intends, rather than trying to emulate it or ask
them to support two installation methods. I see rubygems as the
autoconf/automake of the ruby world, though its missing a few runtime
options that would make dh_rubygems entirely unnecessary.

Reply to: