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.
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
···
On Tue, May 24, 2011 at 4:48 PM, Lucas Nussbaum <lucas@lucas-nussbaum.net>wrote:
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.
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
···
On 25/05/11 at 12:00 +0900, Eric Christopherson wrote:
On Tue, May 24, 2011 at 4:48 PM, Lucas Nussbaum > <lucas@lucas-nussbaum.net> wrote:
> 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?
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).
···
2011/5/25 Eric Christopherson <echristopherson@gmail.com>:
Do the other files belonging to gems still get installed under /var?
So I don't see what a Debian package for rvm could bring.
- Lucas
···
On 06/06/11 at 23:28 +0900, andrew mcelroy wrote:
On Tue, May 24, 2011 at 4:48 PM, Lucas Nussbaum <lucas@lucas-nussbaum.net>wrote:
> 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.
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?
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 popular
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?
···
On Mon, Jun 6, 2011 at 4:28 PM, andrew mcelroy <sophrinix@gmail.com> wrote:
--
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.
-- Leibnitz
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.
···
On Sun, Jun 5, 2011 at 7:24 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
2011/5/25 Eric Christopherson <echristopherson@gmail.com>:
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).
>
> > 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.
What would be the value added by a RVM debian package for Debian users?
>
> 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?
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).
Are you sure you don't mean "upgrade" and "dist-upgrade", rather than
"update" and "upgrade"? All "apt-get update" does is update the package
index. If you're familiar with FreeBSD, it's a bit like "portsnap fetch
update", but for DEB packages rather than for ports.
>
> The RVM metapackage could include all the major dependencies
> that one would reasonably expect to run into with say the 100 most popular
> 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?
Even the number 100 is pretty arbitrary, and I for one wouldn't want all
the dependencies for the 100 most popular gems automatically installed on
my system anyway, because I won't need to install all of the 100 most
popular (or even 50 of them). The idea of installing all the
dependencies for the 100 most popular gems on my system just because I
want Ruby sounds a lot like the kind of thinking that gives me a system
where I can't uninstall Evolution without breaking Pidgin (if I used
Pidgin). The dependency definition philosophy of modern Debian (and
worse, modern Ubuntu) is an exercise in lunacy.
···
On Tue, Jun 07, 2011 at 12:22:08AM +0900, Phillip Gawlowski wrote:
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'd actually agree with that, if it was a version Rubygems I installed myself.
Stuff I install myself should always go somewhere like /usr/local -- somewhere
easy to integrate with the system, but somewhere I know the system package
manager won't touch.
But this isn't quite that, it's another package manager. I'm really not sure
what the FHS has to say about that.
Honestly, I think Gobo and Gentoo have the best approach. I know Gentoo had
something for CPAN, but Gobo has an entire system in place which allows them
to easily add third-party package managers, and have their own packages depend
on those third-party packages. That's the sort of thing that makes me
embarrassed to be using a distro like Ubuntu -- 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?
···
On Sunday, June 05, 2011 08:36:59 PM Eric Christopherson wrote:
On Sun, Jun 5, 2011 at 7:24 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 2011/5/25 Eric Christopherson <echristopherson@gmail.com>:
>> 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).
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.
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.
···
On Mon, Jun 6, 2011 at 6:39 PM, Chad Perrin <code@apotheon.net> wrote:
Are you sure you don't mean "upgrade" and "dist-upgrade", rather than
"update" and "upgrade"? All "apt-get update" does is update the package
index. If you're familiar with FreeBSD, it's a bit like "portsnap fetch
update", but for DEB packages rather than for ports.
--
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.
-- Leibnitz
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).
···
2011/6/6 David Masover <ninja@slaphack.com>:
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?
On Tue, Jun 07, 2011 at 03:11:36AM +0900, Phillip Gawlowski wrote:
On Mon, Jun 6, 2011 at 6:39 PM, Chad Perrin <code@apotheon.net> wrote:
>
> Are you sure you don't mean "upgrade" and "dist-upgrade", rather than
> "update" and "upgrade"? All "apt-get update" does is update the
> package index. If you're familiar with FreeBSD, it's a bit like
> "portsnap fetch 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.
