[DRE-maint] ruby-pkg-tools 0.13: request for review

[Lucas Nussbaum]

On 15/12/07 at 12:44 +0100, Arnaud Cornet wrote:
> Hi, 
> 
> Le vendredi 14 décembre 2007 à 16:59 -0300, Antonio Terceiro a écrit :
> > I just implemented Gunnar's suggestion about using packaged setup.rb to
> > build Ruby packages that doesn't provide one if the maintainer wants to.
> 
> This is neat. I just committed a fix so that the setup.rb link creation
> is done when the building follows another code path: When the control
> file defines package-ruby and package-ruby1.8 then in ruby-setup-rb.mk
> we are in the "regular library" case. My  guess is that you have tested
> with a package that does not have a -ruby1.8 binary package.
 
Hi,

I've tried to rebuild all our packages with the new ruby-pkg-tools.

Many of our packages now fail to build because setup.rb is called with
--installdirs=std . An example is libbreakpoint-ruby:
dh_clean 
[ -f setup.rb ] || ln -s /usr/lib/ruby/1.8/setup.rb setup.rb
/usr/bin/ruby setup.rb config --installdirs=std
config: unknown option --installdirs=std
Try 'ruby setup.rb --help' for detailed usage.
make: *** [clean] Error 1
dpkg-buildpackage: failure: /usr/bin/fakeroot debian/rules clean gave
error exit status 2

The problem is probably that the setup.rb shipped in the package is too
old.

I think that the easiest way to solve that would be to autodetect if the
version of setup.rb shipped in the package is supported or not (using
ruby setup.rb --version) and overwrite it if not supported.
But that's a lot of black magic. Maybe we should just provide a way to
override the package's setup.rb with libsetup-ruby's one.

What do you think?

Anyway, I think that we need to solve this before uploading the new
version.
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |