search

rubyjs / therubyracer

Embed the V8 Javascript Interpreter into Ruby
1.66k stars 193 forks source link

therubyracer on Fedora #278

Closed voxik closed 10 months ago

voxik commented 10 years ago

As you probably noticed, we package therubyracer gem for Fedora for some while already. We would like to update to the most recent version, but the split of libv8 from therubyracer gem makes the things even harder the previously. Let me explain.

Previously, therubyracer bundled some version of v8. We either build against this version or the system version of v8. That was more or less OK.

However, currently, the separated libv8 is at 3.16.14.3 version. If we use the --with-system-v8 switch, it says to therubyracer that it should build against system version, which is currently 3.14.5.10. So the first issue is that libv8 will not correspond with the version of v8 which is actually in use.

Moreover, therubyracer enforces libv8 ~> 3.16.14.0 This in turn means, that every update of libv8 on your side means that we should update as well, although the libv8 in background is not changing.

I must say that all these places us into unfortunate situation of mixture of versions. Do you have any proposal how to get out of this situation? Thanks for your help.

lzap commented 10 years ago

Also I dont understand why --with-system-v8 needs to be provided both in libv8 gem and in therubyracer. I'd expect that libv8 installed with this option is enough.

ignisf commented 10 years ago

Also I dont understand why --with-system-v8 needs to be provided both in libv8 gem and in therubyracer. I'd expect that libv8 installed with this option is enough.

It should only be specified for the libv8 gem.

You have to keep in mind that therubyracer is tested only with the versions of v8 that correspond to the version of the libv8 gem. So the most reliable thing to do would be to package a binary version of the libv8 gem, too. I don't think you should use the version of v8 that your packaging system provides if it is doesn't correspond to the version of libv8 that therubyracer requires.

I do believe that this will cause an issue with the ARM version of the package, as our issue trackers suggest. We have not made any progress for some time on this front, because we have neither the hardware, nor the expertise, or the necessity for that matter, to push forward. I would be happy to work with the people that package v8 for ARM so we can make the libv8 gem compile trouble-free on all the ARM architectures Fedora targets.

lzap commented 10 years ago

Binary packages is a problem as it is against Fedora packaging policy (and Debian and other Linux distributions). We simply cannot (and do not want to) ship binaries that has not been built from sources - for security and legal reasons.

ignisf commented 10 years ago

binaries that has not been built from sources

You mean binary packages that have not been built from the sources by Fedora, right?

A binary version of the gem is built using rake binary. This produces a gem package, specific to the architecture of the host in the pkg subdirectory of the libv8 source tree. Then take the gem from there, unpack it and repack it as an RPM. Is that not how all binary versions of gems such as Nokogiri are packaged?

anupamkumar commented 10 years ago

Hi,

Has anyone found a work around this issue ?

ignisf commented 9 years ago

OpenSUSE are packaging libv8 in source form, see http://rpm.pbone.net/index.php3/stat/4/idpl/23779508/dir/opensuse_12.x/com/rubygem-libv8-3.16.14.1-2.2.x86_64.rpm.html