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 [EMAIL PROTECTED] time ruby -e 'require "image_science"'
real 0m3.165s
user 0m0.408s
sys 0m0.092s
0 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]/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 [EMAIL PROTECTED]/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 [EMAIL PROTECTED]/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 - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
