almost ready, waiting for @brixen to confirm
add support for binary rbx
Merge branch 'master' into features/binary-rbx
waiting for something more to test:
curl -L http://binaries.rubini.us/ | grep -oE "<Key>[^<]+</Key>" | sed 's/<[^>]*>//g' | grep -vE '\.md5$|\.sha1$|\$folder\$$'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7212 0 7212 0 0 10559 0 --:--:-- --:--:-- --:--:-- 17130
@mpapis could you elaborate? What are you waiting for, more binaries? Does that mean I can install these binaries now with RVM? If so, what are the install instructions so I can confirm?
I would vote for updating the root of your package so it can be easily used with other ruby switchers like https://github.com/postmodern/chruby //cc @postmodern
Ruby switchers are by definition not installers and simply use whatever directory structure is provided.
The Rubinius binaries are general purpose and use a reasonable *nix path. They will not be made special for RVM. If you choose to create your own binaries or repackage Rubinius binaries, that's up to you, but the digests will no longer match and you assume responsibility for security. We will be signing packages soon and I will advocate everywhere not using any binary package that is not signed by us.
You already have conditional code in RVM for dealing with a myriad situations. The code to unpack a binary in a single dir is not at all complex. You are asking that I make an exception for RVM when all you have to do is mkdir foo; cd foo; <unpack>. Your insistance on special treatment for RVM exceedingly unreasonable.
mkdir foo; cd foo; <unpack>
I am removing the melbourne/build directory from installs, so you should remove that code from RVM.
I'll add .tar.gz and .tar.bz2 versions of the binaries.
@brixen actually I'm considering other tools, especially taking chruby into consideration: https://github.com/postmodern/chruby#system-wide where rubies are unpacked in /opt/rubies/ your path makes it complicated by requiring additional actions:
which would be enough if you follow my advise to use the same root dir as the package, but with your root user has two more steps:
mv usr/local/rubinius/2.0.0rc1 rubinius-2.0.0-nightly20121210-d18
rm -rf usr
which is required to allow multile versions like rubinius-2.0.0-nightly20121210-d18 and rubinius-2.0.0-nightly20121210-d19
No, it doesn't require additional steps. The switchers do not have to care where the files are. Especially if they are working with system package installs as well, they are already accounting for different paths.
so you can extract rubinius-2.0.0-nightly20121210-d18 and rubinius-2.0.0-nightly20121210-d19 and they will have different roots? btw. for system packages you will have to prepare a new package anyway, so I do not see a point in your reasoning, especially, /usr/local/ is not a good path according to FHS which is requirement for Ubuntu
The binary is not for system packages. System packages are built with our build system for the requirements of different packagers.
No, they don't have different roots, but they will coexist side-by-side just like different versions do.
brixen so continuing chruby (to avoid rvm) could you give me simple instruction how to use rbx with chruby?
@mpapis you are wasting my time and I have much more important things to spend it on. You know where Rubinius binaries are. If you decide to install them with RVM, I think your users will thank you. If not, they can install from source and it will be a good reason to consider an alternative Ruby installer. I am dedicating the time I have wasted on RVM bugs and problems to packages for popular platforms and features that Rubinius users need.
take into account that rbx does not have proper package root
@joshk you can try with this commands:
sudo apt-get install unzip
rvm get branch /features/binary-rbx
rvm install rubinius-2.0.0-nightly20121209-d18 --verify-downloads 1
Chiming in here. @brixen the archives should probably not include usr/local/ prefix, but instead use the -C option for tar and the -d option for unzip.
tar -xzvf rubinius-bin.tar.gz -C /usr/local
unzip rubinius-bin.zip -d /usr/local
This would also allow chruby users to manually download the rubinius binaries, and extract them where ever; I prefer /opt/rubies/ as it complies with the FHS
ok all important changes are already on head, here is only http://binaries.rubini.us/ specific code.
all changes except https://github.com/wayneeseguin/rvm/pull/1378/files#L0R79 would be obsolete if the archive would be adjusted:
I have prepared example build (ubuntu/12.04/i386) of rbx that works without this changes (it's hosted on http://rvm.io):
rvm get head
rvm install rubinius-2.0.0-nightly20121218-d19 --verify-downloads 1 --binary
rubinius prefers tar.gz, update #1378
use proper extensions for "rvm prepare rbx-...", update #1378
remove excluded_libs for melbourne/build/melbourne20, reverts part of e…
I've uploaded a new set of test binaries for the precise32 (ubuntu/12.04/i386) platform. The following are changes:
great I will do some release to include it tomorrow (quite tired today) ... one question: the internal directory structure does not reflect the archive name, is it intentional? I think it could be an issue when trying next versions of RBX.
also is there a tagged release that corresponds weekly (daily seams to much for a tag)?
There will be weekly and rc tags along with the release tags eventually. The weekly and nightly binaries are intended to install in the same place so that someone can update to the most current one easily.
simplify/improve code for importing binary rubies (jruby/rbx usecase)
fix quoting wildcards, fix 3c7feb0
improve error messages for binary rubies installation
remove target ruby dir to prevent problems with old stuff
extract archive validation to separate function, rename binary valida…
rubinius decided to use tar.bz2 in the end