[DRE-maint] Packaging a module built with libinline-ruby

[Gunnar Wolf]

Hi,

I just sent an ITP for libimage-science-ruby [1,2], and have the package
basically ready for upload (in fact, just after this mail I will
polish some details, and inject it into our packages-wip). However,
there is something that bugs me regarding this module - and that will
probably reflect on bugs on other packages :-/

libimage-science-ruby basically provides a thin layer, providing Ruby
access to some functinos of the FreeImage library (see pkg
libfreeimage-dev). This is done by embedding C code through
libinline-ruby. Building the package is very easy and straightforward,
and everything is joyous so far.

However (why must there always be a catch?), when first running any
code using this library, we get this:

0 gwolf at malenkaya[2]~$ time ruby -e 'require "image_science"'

real		       0m3.165s
user		       0m0.408s
sys		       0m0.092s
0 gwolf at malenkaya[3]~$ time ruby -e 'require "image_science"'

real		       0m0.089s
user		       0m0.072s
sys		       0m0.016s

Why? Simple: because the inline code must be compiled. So:

0 gwolf at malenkaya[4]~$ find .ruby_inline/
.ruby_inline/
.ruby_inline/Inline_ImageScience_aa58.so
.ruby_inline/Inline_ImageScience_aa58.c

The C file is generated from the Ruby module - And it's quite nicely
generated, pointing to its original location and all. And if I delete
the directory, it will be resurrected - all nice, all happy. 

However, IMHO it's not adequate for a Debian package. First, this
might lead to _very_ long startup times when dealing with slightly
more complex code and on slower architectures. Second, this creates
-although in the user's home directory- a set of pseudo-source and
object files which are not managed via dpkg. But third, and most
important, because some users will not have the right to create files
in their home directories - I'm thinking, i.e., about users hosting
webapps (yes, I'm that pesky Rails guy again). Obscure messages will
be given in this case:

1  root at malenkaya[1]/home/gwolf# su - nobody -c 'ruby -e "require \"image_science\""'
No directory, logging in with HOME=/
/usr/lib/ruby/1.8/inline.rb:325:in `mkdir': Permission denied -
/.ruby_inline (Errno::EACCES)
	      from /usr/lib/ruby/1.8/inline.rb:325:in `build'
	      from /usr/lib/ruby/1.8/inline.rb:709:in `inline'
	      from /usr/lib/ruby/1.8/image_science.rb:84
	      from -e:1:in `require'
	      from -e:1

There are ways around this, although I'm not exactly happy with them:
We can set an environment variable INLINEDIR [3], so that the
directory is under /tmp or something like that:

0 root at malenkaya[4]/home/gwolf# su - nobody -c 'export INLINEDIR=$(mktemp -d);ruby -e "require \"image_science\""'

But of course, this will incur in compiling overhead at each
invocation. And there are many possible ways out, but
they are always left for the admin to decide/solve.

What I would favor is to provide a mechanism analog to Python's
byte-compilation - but right now, this could mean some hackery on top
of Inline. This would amount to specifying a directory where modules
should be compiled to at install time (and purged from at purge time),
and where Inline would search for object files, probably at a lower
precedence than ~/.ruby_inline.

This would, of course, solve the particular problem for this module,
for which the inlined C code is statically included as strings in the
module source, although would be useless on cases where the compiled
code is dynamically generated - but I think most of the uses would
fall into the first category.

Then again, this might be just overkill... I can also just ship this,
with the issue (and workarounds) documented in README.Debian.

As for other packages using Inline: Currently, only two packages
depend on libinline-ruby1.8: libvalidatable-ruby1.8 and
libparsetree-ruby1.8. I even think libvalidatable-ruby1.8's dependency
is spurious, just at a quick glance:

0 gwolf at malenkaya[3]/tmp/libvalidatable-ruby-1.6.7$ grep -ri inline .|grep -v debian
./rakefile.rb:  task.options << "--line-numbers" << "--inline-source"

As for libparsetree-ruby1.8, it has the exact same effect I described
earlier. 

So... To make a long mail short: Do you think documenting the issue is
enough? Is an inlined code tracker overkill? Or does it look useful?

[1] http://bugs.debian.org/499196

[2] http://seattlerb.rubyforge.org/ImageScience.html

[3] http://mandarinsoda.com/2008/03/09/image-science-ruby-inline-and-your-sanity/

-- 
Gunnar Wolf - gwolf at gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF