Changes for Ruby in Debian (and Ubuntu)

Discussion in 'Ruby' started by Lucas Nussbaum, May 24, 2011.

  1. Hi,

    Since the beginning of 2011, the Debian Ruby team has been working on
    several big changes. Those changes all are available in Debian unstable,
    some of them are also available in Debian testing, and they should all
    be available in the next Debian and Ubuntu releases.

    I think that it addresses most of the reasonable concerns about Ruby in

    Using alternatives to switch between Ruby implementations
    The alternatives system is now used to manage the "ruby" symlink and the
    other related symlinks, making it easy to switch between Ruby
    implementations (only Ruby 1.8 and 1.9.X at the moment). The default
    choice for Ruby is still 1.8, but this change will make it easy for us
    to make a switch to 1.9.X by default (likely by the release of Debian

    Installing gems executables to /usr/local/bin
    Rubygems (both as a standalone package, and as shipped with Ruby 1.9.X)
    now install executables to /usr/local/bin.

    Enabling gem update --system
    gem update --system has been re-enabled. Since upgrading rubygems to a
    version that may not have been properly tested with the rest of the
    Debian system may cause issues in the user's system, there's a big
    warning about that. The user can confirm and upgrade rubygems anyway by
    defining an environment variable.

    New gem2deb packaging helper
    There's a new packaging helper, named gem2deb, that makes it very easy
    to generate Debian source packages from Rubygems. We are in the process
    of migrating all ruby libraries packaged in Debian to that new helper.
    It will take some time, though (help is welcomed).
    transition status:

    One big benefit of the switch to gem2deb for the Ruby community is that,
    in the process, we are enabling test suites at build time for each
    package and each Ruby implementation. This should make it easy to detect
    regressions in new interpreter versions.

    Ruby 1.9.3
    We will switch to Ruby 1.9.3 ASAP (probably when it is branched off
    trunk, with a package first in Debian experimental). Since the Ruby
    compatibility version issue is likely to stay around, we will
    re-evaluate how we are dealing with it (to avoid the ruby1.9.1 package
    <=> ruby -v = 1.9.2 problem that confuses many users). This is likely by
    switching the package name to ruby1.9.3 (keep a ruby1.9.1 package for
    compatibility). The package containing the shared library will stay

    team website:
    contact point:
    IRC: #debian-ruby @

    - Lucas (for the Debian Ruby team)
    Lucas Nussbaum, May 24, 2011
    1. Advertisements

  2. Do the other files belonging to gems still get installed under /var?
    Eric Christopherson, May 25, 2011
    1. Advertisements

  3. Yes. The Debian changelog says:
    * Change 01_default_gem_path.diff:
    + executables are now installed to /usr/local/bin.
    + but the other files created by rubygems stay in /var/lib/gems/1.8.
    Several commenters in #448639 and #403407 argued in favor of the switch to
    /usr/local/bin. Those two bugs can therefore be closed. However, the issue
    is not completely solved, as rubygems still installs files in /var/lib/gems.
    Nobody in the bug logs explained why that was an issue. If you care about
    it, please open a new bug. Closes: #448639, #403407

    Moving off /var/lib/gems also requires a transition plan, which is not so
    obvious. Just ignoring gems that were previously installed is a possibility,
    but not a very good idea IMHO.

    - Lucas
    Lucas Nussbaum, May 25, 2011
  4. I've never understood why libraries should be installed under /var
    directory. /usr/lib/ exists for that: for storing libraries. /var si
    supposed to contain dynamic content (cache files, logs, mails, PID
    files, daemons sockets, and so no, but not libraries).

    I=C3=B1aki Baz Castillo
    Iñaki Baz Castillo, Jun 6, 2011
  5. As I understand it, they're not in /usr/bin because they're not
    installed by the package manager. That much I can agree with. But I
    would put them in /usr/local. I guess the rationale is that /var is,
    by definition, a location that is writeable, and gem installation
    writes files, so they go there. I'm not sure how many gems actually
    modify their files once they're installed; I would guess not many.

    It may be a prejudice or misconception on my part, but I'm used to
    thinking of /var as containing stuff I don't really need to worry
    about backing up. I guess that doesn't necessarily conflict with gems
    though, since they can usually be reinstalled after a recovery; but
    that's true of .deb packages too, so I dunno.
    Eric Christopherson, Jun 6, 2011
    David Masover, Jun 6, 2011
  7. You might want to double-check that you backup /var/lib/mysql, one way
    or another.

    Lucas Nussbaum, Jun 6, 2011
  8. By having, for example, a ruby1.9.1-mysql2.deb package, you don't need
    to install mysql development libraries into your system. Neither you
    need to *manually* manually mysql user library as the DEB package
    would install (due dependencies).

    I=C3=B1aki Baz Castillo
    Iñaki Baz Castillo, Jun 6, 2011
  9. [Note: parts of this message were removed to make it a legal post.]

    Any chance of getting RVM as a debian package?
    Also, I've been following this thread. I am still unclear as to why there is
    such a need to have a gem2deb translation. Wouldn't a better solution be to
    have a meta package for RVM and let rvm with rubygems handle gems/ their
    dependencies? The RVM metapackage could include all the major dependencies
    that one would reasonably expect to run into with say the 100 most popular

    Andrew McElroy
    andrew mcelroy, Jun 6, 2011
  10. What would be the value added by a RVM debian package for Debian users?

    Even if I'm not, I thought that RVM users were happy with the current
    installation procedure of doing
    bash < <(curl -s

    So I don't see what a Debian package for rvm could bring.

    - Lucas
    Lucas Nussbaum, Jun 6, 2011
  11. [Note: parts of this message were removed to make it a legal post.]

    Standardization. More on this later.
    andrew mcelroy, Jun 6, 2011
  12. Two package managers create double the work for maintenance, and
    that's when the package managers are pretty much identical, not to
    mention that "gem update" updates the release *and* the patchlevel,
    while "apt-get update" only updates the patchlevel ("apt-get upgrade"
    updates the release level).

    And consider, for example, "gem install psych". It has an external (to
    Ruby) dependency (libyaml.h), that RubyGems cannot satisfy without
    creating loads of overhead, but "apt-get install libruby-psych" *can*.
    And these 100 gems are a one-size fits all package? And I can't ever
    get rid of them? Who's curating this list? Will it change when
    something becomes popular? How is "popular" defined, anyway? And why
    would I want a compiler on a webserver serving Rails apps? Is your RVM
    meta-package locked down so well that nothing, ever, can use the
    compiler for nefarious purposes? What about the 95 included RubyGems
    that I don't use, yet are there and increase the surface of attack for
    my server?

    Phillip Gawlowski

    A method of solution is perfect if we can forsee from the start,
    and even prove, that following that method we shall attain our aim.
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Leibnitz
    Phillip Gawlowski, Jun 6, 2011
  13. Er, yes. It's been a long, long while since I had to use apt in any serious=

    "pacman -Su" is about the maximum of time I want to invest into
    package maintenance, anyway. ;)

    Phillip Gawlowski

    A method of solution is perfect if we can forsee from the start,
    and even prove, that following that method we shall attain our aim.
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Leibnitz
    Phillip Gawlowski, Jun 6, 2011
  14. This is a very good point. I neither want to compile gems in my
    production server, not if Debian provides me pre-compiled packages and
    handles dependencies automatically.

    Why should I need to install libmysqlclient-dev, ruby-dev and gcc in
    my server just to install mysql2 gem? My server is a server, not a
    personal computer in which I experiment, compile and code. If Debian
    provides "ruby-mysql2" DEB package, running "apt-get install
    ruby-mysql2" in my server is all I need (and avoid installing
    development libraries and compiling).

    I=C3=B1aki Baz Castillo
    Iñaki Baz Castillo, Jun 7, 2011
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.