[DRE-maint] ruby-pkg-tools 0.13: request for review
lucas at lucas-nussbaum.net
Mon Dec 24 08:20:27 UTC 2007
On 15/12/07 at 12:44 +0100, Arnaud Cornet wrote:
> 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.
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:
[ -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
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
| Lucas Nussbaum
| lucas at lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr GPG: 1024D/023B3F4F |
More information about the Pkg-ruby-extras-maintainers