Changes for Ruby in Debian (and Ubuntu)

[Lucas Nussbaum]

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
Debian.

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
wheezy).

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: http://pkg-ruby-extras.alioth.debian.org/wheezy/

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
libruby1.9.1.

Links
=====
team website: http://wiki.debian.org/Teams/Ruby
contact point: (e-mail address removed)
IRC: #debian-ruby @ irc.debian.org

- Lucas (for the Debian Ruby team)

 

[Eric Christopherson]

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.

Do the other files belonging to gems still get installed under /var?

 

[Lucas Nussbaum]

Do the other files belonging to gems still get installed under /var?

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

 

[Iñaki Baz Castillo]

Do the other files belonging to gems still get installed under /var?

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).

--=20
I=C3=B1aki Baz Castillo
<[email protected]>

 

[Eric Christopherson]

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).

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.

 

[David Masover]

=20
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'd actually agree with that, if it was a version Rubygems I installed myse=
lf.=20
Stuff I install myself should always go somewhere like /usr/local -- somewh=
ere=20
easy to integrate with the system, but somewhere I know the system package=
=20
manager won't touch.

But this isn't quite that, it's another package manager. I'm really not sur=
e=20
what the FHS has to say about that.

Honestly, I think Gobo and Gentoo have the best approach. I know Gentoo had=
=20
something for CPAN, but Gobo has an entire system in place which allows the=
m=20
to easily add third-party package managers, and have their own packages dep=
end=20
on those third-party packages. That's the sort of thing that makes me=20
embarrassed to be using a distro like Ubuntu -- why do I have tons of packa=
ges=20
called libruby-foo, which are a Ruby library (often a gem) repackaged as dp=
kg,=20
when I already have rubygems to do the work?

 

[Lucas Nussbaum]

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.

You might want to double-check that you backup /var/lib/mysql, one way
or another.

L.

 

[Iñaki Baz Castillo]

why do I have tons of packages
called libruby-foo, which are a Ruby library (often a gem) repackaged as = dpkg,
when I already have rubygems to do the work?

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).



--=20
I=C3=B1aki Baz Castillo
<[email protected]>

 

[andrew mcelroy]

[Note: parts of this message were removed to make it a legal post.]

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.

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
rubygems.

Andrew McElroy

 

[Lucas Nussbaum]

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
rubygems.

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 https://rvm.beginrescueend.com/install/rvm)

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

- Lucas

 

[andrew mcelroy]

[Note: parts of this message were removed to make it a legal post.]

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 https://rvm.beginrescueend.com/install/rvm)

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

Standardization. More on this later.

 

[Phillip Gawlowski]

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 =A0and let rvm with rubygems handle gems/ the= ir
dependencies?

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*.

The RVM metapackage could include all the major dependencies
that one would reasonably expect to run into with say the 100 most popula= r
rubygems.

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?

--=20
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]

Are you sure you don't mean "upgrade" and "dist-upgrade", rather than
"update" and "upgrade"? =A0All "apt-get update" does is update the packag= e
index. =A0If you're familiar with FreeBSD, it's a bit like "portsnap fetc= h
update", but for DEB packages rather than for ports.

Er, yes. It's been a long, long while since I had to use apt in any serious=
way.

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

--=20
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

 

[Iñaki Baz Castillo]

And why would I want a compiler on a webserver serving Rails apps?

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).

--=20
I=C3=B1aki Baz Castillo
<[email protected]>