Live data from Hacker News

Next Generation Ruby packages for Ubuntu

blog.brightbox.co.uk

1–10 of 21 posts

Re: Next Generation Ruby packages for Ubuntu

#5
This looks pretty good - it's always painful installing packages from source (RVM included in that) mainly as a time + another thing I have to maintain thing.

I'm not that familiar with Debian package management but would it be much work to also have these packages working on squeeze too? In which case I would most likely start using Debian a lot more.

Re: Next Generation Ruby packages for Ubuntu

#6

This looks pretty good - it's always painful installing packages from source (RVM included in that) mainly as a time + another thing I have to maintain thing. I'm not that familiar with Debian package management but would it be much work to also have these packages working on squeeze too? In which case I would most likely start using Debian a lot more.

They should build without much modification - it just needs a bit of effort to setup a repository and do the builds. If there is demand for it, we could look at doing it.

Re: Next Generation Ruby packages for Ubuntu

#9

  Added Sokolov Yura‘s performance patches for 1.9.3
  Added Narihiro Nakamura’s Lazy Sweep garbage collector (backported by Sakolov Yura)
Why isn't this work a part of an official ruby release?

  Patched Ruby 1.9.3 to export the right symbols to work with ruby-debug
  Built Ruby 1.9.3 with Google’s high performance memory alloactor, tcmalloc
Why aren't Debian and Ubuntu doing this already?

Re: Next Generation Ruby packages for Ubuntu

#10
post #9

Added Sokolov Yura‘s performance patches for 1.9.3 Added Narihiro Nakamura’s Lazy Sweep garbage collector (backported by Sakolov Yura) Why isn't this work a part of an official ruby release? Patched Ruby 1.9.3 to export the right symbols to work with ruby-debug Built Ruby 1.9.3 with Google’s high performance memory alloactor, tcmalloc Why aren't Debian and Ubuntu doing this already?

imo, I don't think Debian and Ubuntu should do this - it's not really their job. Distros should, for the most part, just be packaging upstream code and not maintaining an unofficial fork.

Though counter to this, RedHat basically maintain their own fork of the Linux kernel but it's a bit of a special case, and they do employ full time kernel developers to do it!

Post reply on HN