Recommended way to install Rubygems

[Rick DeNatale]

On 18/03/10 at 23:05 +0900, Nick Brown wrote:

In Debian, we do not ship software without appropriately describing what
other packages are required (as dependencies) to use it. ruby1.8-elisp
is a separate package that depends on emacs, so that is fine. But if we
wanted to ship the content of ruby1.8-elisp inside an hypothetical
full-featured ruby package, the right thing to do would be to depend on
emacs. This could become an interesting issue on some of the
architecture debian supports.


OpenSSL doesn't have a lot of fans, because of its licence that prevents
it from being linked to GPL software. Yes, it could be possible to ship
openssl.so and readline.so in the same package, but then it would be
harder to argue that Debian does enough to protect the linking of
readline (GPLv2) with openssl. The situation would be much simpler if
Ruby switched to GNU TLS, for example.


I really think that this problem is a minor one, and not worth all the
noise around it. I'll see with the other maintainers if there's a way we
can improve the situation slightly. But the licensing issues involved
make me fear that it is unlikely.

Really, sometimes the requirements of keeping the packages in a distro
in-line are at odds with what some users need to do with the software
being packaged.

Not trying to be controversial here, but the discussion could be about
who owns Jerusalem.

The Debian policies are aimed at keeping the overall system under
control moving from one consistent set of package versions to another.

For some people that works well, even for Ruby. But others have the
requirement to treat components in a more flexible way.

For example, we might need to run different versions of gems on the
same machine for different applications. We might run applications
using different versions of Rails, again for example. This is why
gems has the unpack command and why Rails allows gems to be vendored.
The base capability to have multiple versions of gems installed at the
same time is key. Gems which have been converted to (debian) packages
lose this ability, I think.

We might need to run multiple versions of Ruby on the same system,
including 1.8.6, 1.8.7 and 1.9.x If the package maintainer views
1.8.6 and 1.8.7 as the same 'version' this is problematical.

Rubyists have developed solutions like ruby switcher and rvm to deal
with this requirement.

If packaged Ruby works for someone, fine. For a long time I've been
installing Ruby and rubygems from source on my Debian/Ubuntu systems,
as well as on my OS X machines, in a directory outside of the
territory claimed by the OS, at first manually and now with rvm.

If the packaged version of Ruby is used at all on my machines, it's
only by other packages which pre-req it, not by code I write.

That's not a reason to consider it acceptable.

True enough, OTOH, I've found it a lot easier to live on the
inter-tubes if I develop a thick skin, and give everyone the benefit
of the doubt that they are not actively trying to be uncivil, even if
they express themselves in what I might perceive to be an uncivil
fashion.

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Lucas Nussbaum]

<wikipedia>Citation Needed</wikipedia>

(give me BSD-licensed code any day)

http://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_.28original_.22BSD_License.22.29
(which is the version of the BSD license that OpenSSL uses. If it was
the 3-clauses BSD license, there would be no problem.)

 

[Lucas Nussbaum]

Your first sentence is incorrect; OpenSSL is both better known and
more widely used in the real world than GNU TLS is likely to ever be.
GNU TLS is preferred by people who have subscribed to the GNU
philosophy, which doesn't include everyone in the Ruby world, and
those of us who prefer OpenSSL see GNU TLS as a zany outlier created
by people who have nothing better to do with their time than to worry
about the attribution clause (I believe that's the part that makes GNU
software incompatible with OpenSSL licensing, since GNU believes that
attribution isn't necessary).

That said, if someone were to make an SSL/TLS layer for Ruby that
could reasonably replace the OpenSSL namespace and that both "require
'openssl'" and "require 'gnutls'" would satisfy, then I think we'd see
traction. Since this is apparently a problem for people who prefer GNU
TLS, I suggest that it is in their interest to do so.

Note that your lawyer might disagree with you, whether he is a GNU
fanboy or not, because it is widely agreed that the OpenSSL license is
incompatible with the GPL.

I agree that this sucks, but hey, that's life.

 

[Lucas Nussbaum]

I completely agree that the split sucks. We run a Ruby service that
requires our users to install a simple script on their servers. It
does use net/https to communicate, so about 80% of our support issues
on Debian systems are us explaining to users how to finish their Ruby
install.

In my opinion, the problem is that the Debian maintainers have changed
what it means to install Ruby. That's not OK to me, because it's not
their call to make. The Ruby core team gets to decide what it means
to install Ruby.

Apparently, the ruby core team is OK with the current situation, since
apt-get install ruby1.9.1-full/ruby-full is advertised on
http://www.ruby-lang.org/en/downloads/. You might want to educate your
users to read the documentation.

Also, I disagree that it's not our call to make. Most of the software
shipped by Debian is split in seperate packages, and Ruby is the only
case where I hear people complaining about such a minor issue.

(Also note that the split predates me being involved in Ruby
maintenance.)

All of the standard libraries are meant to be
installed so you can count on having them. By changing that decision,
Debian has made it so you can't count on having them and that changes
the rules of what you can do with Ruby.

If, maybe, the Ruby community fixed the fact that it's illegal to load
all of stdlib in the same process (because of OpenSSL vs GPL), we could
consider including ssl and readline in the default lib pkg. However, I don't
see how we will make Ruby depend on installing Tcl/Tk (because of the TK
bindings), or Emacs (because of the ruby mode for emacs). Note that even
ruby-full doesn't install the TK and elisp stuff.

 

[Lucas Nussbaum]

For example, we might need to run different versions of gems on the
same machine for different applications. We might run applications
using different versions of Rails, again for example. This is why
gems has the unpack command and why Rails allows gems to be vendored.
The base capability to have multiple versions of gems installed at the
same time is key. Gems which have been converted to (debian) packages
lose this ability, I think.

We might need to run multiple versions of Ruby on the same system,
including 1.8.6, 1.8.7 and 1.9.x If the package maintainer views
1.8.6 and 1.8.7 as the same 'version' this is problematical.

Rubyists have developed solutions like ruby switcher and rvm to deal
with this requirement.

Note there are not many development communities that are proud of the
fact of having different, incompatible versions of the same software
being widely used at the same time.

Most other communities solve that by having more stable APIs and making
sure that their important software supports the latest API.

In Debian Squeeze (next Debian release), we ship (and support for
several years) ruby 1.8 (likely 1.8.249+some backports) and ruby 1.9.1
(maybe a prerelease of 1.9.2, but unlikely). It would be totally insane,
to, additionally, try to support several versions of the same libraries.
Of course, if you want to install many different Ruby and gems versions,
and then try to keep them in a sensible state wrt security issues (which
are not that uncommon in the ruby world), that's your choice.

True enough, OTOH, I've found it a lot easier to live on the
inter-tubes if I develop a thick skin, and give everyone the benefit
of the doubt that they are not actively trying to be uncivil, even if
they express themselves in what I might perceive to be an uncivil
fashion.

It's really to give the benefit of the doubt about civility to several
people on this list.

 

[James Edward Gray II]

=20
Apparently, the ruby core team is OK with the current situation, since
apt-get install ruby1.9.1-full/ruby-full is advertised on
http://www.ruby-lang.org/en/downloads/. You might want to educate your
users to read the documentation.

I added that to the site recently to help with this issue. (It was =
recommended by another user running into the same problem, so I don't =
think I'm totally alone.)

Also, I disagree that it's not our call to make. Most of the software
shipped by Debian is split in seperate packages, and Ruby is the only
case where I hear people complaining about such a minor issue.

I find you calling the legitimate complaint that some of us are trying =
to explain to you civilly, "such a minor issue," at least as offensive =
as those of our community who have been rude to you. I build Ruby =
software for a living and Debian's packaging does increase our support =
issues. Please respect that I have a viable opinion.

=20
If, maybe, the Ruby community fixed the fact that it's illegal to load
all of stdlib in the same process (because of OpenSSL vs GPL), we = could
consider including ssl and readline in the default lib pkg.

Ruby obviously ships these libraries together without issue. I assume =
it's because the responsibility falls to the user not to load them in =
some illegal situation.

I don't see how that wouldn't be OK for Debian too. Obviously it is, =
since you do offer full install options, right?

Or am I misunderstanding something? (Very possible, as I am not an =
expert in these matters.)

James Edward Gray II

 

[James Edward Gray II]

Note there are not many development communities that are proud of the
fact of having different, incompatible versions of the same software
being widely used at the same time.

Most other communities solve that by having more stable APIs and making
sure that their important software supports the latest API.

Of course, if you want to install many different Ruby and gems versions,
and then try to keep them in a sensible state wrt security issues (which
are not that uncommon in the ruby world), that's your choice.

You have lost the high ground in the civility argument.

James Edward Gray II

 

[Lucas Nussbaum]

I added that to the site recently to help with this issue. (It
was recommended by another user running into the same problem, so I
don't think I'm totally alone.)


I find you calling the legitimate complaint that some of us are trying
to explain to you civilly, "such a minor issue," at least as offensive
as those of our community who have been rude to you. I build Ruby
software for a living and Debian's packaging does increase our support
issues. Please respect that I have a viable opinion.

"Such a minor issue" was the split of many software packages into
seperate Debian packages, not the split of Ruby. Sorry if I have
offended you.

Interestingly, we don't get many complaints on the Debian side about
that. The only place where I hear about it is on this list.

Ruby obviously ships these libraries together without issue. I assume
it's because the responsibility falls to the user not to load them in
some illegal situation.

I don't see how that wouldn't be OK for Debian too. Obviously it is,
since you do offer full install options, right?

Or am I misunderstanding something? (Very possible, as I am not an
expert in these matters.)

No, it just seems easier to ship everything in the same binary package
if this doesn't add a dubious licensing situation (but IANAL).

Also, the licensing issue will bite us (Debian) quite soon anyway.
Currently, we ship Ruby linked to libreadline5 (which is GPLv2). It is
likely that there will be a push to switch to libreadline6 (GPLv3), and
that will put us in an interesting situation when Ruby will be the only
application not having been switched to libreadline6.

 

[Lucas Nussbaum]

You have lost the high ground in the civility argument.

Why? What do you disagree with?

 

[James Edward Gray II]

=20
Why? What do you disagree with?

I wasn't agreeing or disagreeing with anything. I was pointing out that =
you yourself have stopped being civil in the quoted comments above.

James Edward Gray II=

 

[Lucas Nussbaum]

I wasn't agreeing or disagreeing with anything. I was pointing out
that you yourself have stopped being civil in the quoted comments
above.

I disagree. I think that the following are true:
- changing APIs is not considered a big problem in the ruby community
- there are several versions of the interpreter being all widely used
(ruby 1.8.6, 1.8.7, and to a lesser degree unfortunately, 1.9.X)
- other scripting languages don't have as many API problems as ruby
(look at perl or python -- well, python has some for python 3.X)
- ruby has had several security issues over the past year. Every complex
and famous software package has some, that's life. But managing
security when you have several versions co-installed manually is
harder than when you just have to 'apt-get upgrade'.

Note that I'm a Ruby fan, and also a ruby library developer. I'm the
original author for XMPP4R, for example. What I wrote above are just
*facts* about Ruby, not insults.

 

[Rick DeNatale]

I find the massive and rapid open source contributions to the overall
Ruby ecosystem to be a big source of pride in the Ruby community.

The fact that not everything needs to be on the same version of
everything is what allows fast movement.

Now I realize that there's a different mindset between cutting-edge
development to deployment to system administration. Clearly having
less stability in the various pieces that make up various applications
raises some issues, and we, the Ruby community have been dealing with
those issues and getting better at it as time goes on.

Allowing that 'instability' is important to a lot of us, believe it or not.

As I said before packaged Ruby solutions and re-packaged gems have
their place, they work for some users, but not for all.


In another reply to this thread you said:

Such a minor issue" was the split of many software packages into
seperate Debian packages, not the split of Ruby. ...

Interestingly, we don't get many complaints on the Debian side about
that. The only place where I hear about it is on this list.

I'm not sure what the antecedent of 'that' in the first sentence in
the second paragraph is. But I guess it doesn't matter. Perhaps the
reason you only hear complaints about the debian packaging of Ruby and
gems here is that there's a much higher proportion of users here who
are actually leveraging Ruby in such a way as to have conflicting
requirements with those of the debian packagers.

And as I said before, it's not really an either or. You can run both
packaged ruby/gems if you need to in order to run other packages which
require them, along with multiple other installations outside of the
file system space clamed by debian policy within the FHS.

This whole discussion reminds me of the endless static vs. dynamic
typing debate. Some feel strongly that one should live within a
highly constrained infrastructure, others see benefits in having more
freedom of action, and are willing to deal with the consequences and
use tools and techniques which do that.

Why? What do you disagree with?

I can't speak for James but perhaps he was reacting to the remark
about security issues not being uncommon in the ruby world.

In fact, although there have been security patches to Ruby/Rails etc.
They haven't been more frequent than most other OSS software as far as
I have experienced, and certainly less than software from a certain
company headquartered in the US Pacific Northwest. And such security
patches are generally released quickly.

In fact having the ability to apply such changes, without having to
wait for them to be packaged 'downstream' is another advantage to
allowing 'instability.'


--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Lucas Nussbaum]

I'm not sure what the antecedent of 'that' in the first sentence in
the second paragraph is. But I guess it doesn't matter. Perhaps the
reason you only hear complaints about the debian packaging of Ruby and
gems here is that there's a much higher proportion of users here who
are actually leveraging Ruby in such a way as to have conflicting
requirements with those of the debian packagers.

That's very true. Note that, on the Debian side, we totally acknowledge
that Rubygems fills a need for some people (Ruby developers who want the
cutting edge software). However, the vision (from a part of the ruby
community) where everybody using Debian/Ubuntu is using apt-get to
install their normal application, but rubygems to install their ruby
applications, is not a realistic one.

I can't speak for James but perhaps he was reacting to the remark
about security issues not being uncommon in the ruby world.

In fact, although there have been security patches to Ruby/Rails etc.
They haven't been more frequent than most other OSS software as far as
I have experienced, and certainly less than software from a certain
company headquartered in the US Pacific Northwest. And such security
patches are generally released quickly.

In fact having the ability to apply such changes, without having to
wait for them to be packaged 'downstream' is another advantage to
allowing 'instability.'

Heh, I never wrote that Ruby is a security nightmare There are
security issues in Ruby too, so that's something to take into account
when considering several versions of ruby concurrently and from source.
I agree that the Ruby security history is not particularly bad.

 

[James Edward Gray II]

I think that the following are true:

- there are several versions of the interpreter being all widely used
(ruby 1.8.6, 1.8.7, and to a lesser degree unfortunately, 1.9.X)

We don't do this because we prefer it that way. Our language is in =
transition.

- other scripting languages don't have as many API problems as ruby
(look at perl or python -- well, python has some for python 3.X)
- ruby has had several security issues over the past year. Every = complex
and famous software package has some, that's life. But managing
security when you have several versions co-installed manually is
harder than when you just have to 'apt-get upgrade'.

These strike me as gross over generalizations.

James Edward Gray II=

 

[Nick Brown]

I really think that this problem is a minor one, and not worth all the
noise around it.

It may be a minor problem on the individual level, but a minor problem
which is very wide-spread becomes a much larger problem cumulatively.
Just changing the way the packages are named would probably solve this
minor-yet-common usability issue.

I'll see with the other maintainers if there's a way we
can improve the situation slightly. But the licensing issues involved
make me fear that it is unlikely.

Awesome, thanks for checking! Maybe making the "ruby" package part of
the repository that isn't picky about licenses, and putting the
"ruby-minimal" package in the standard repository would help...

That's not a reason to consider [a rude tone] acceptable.

Agreed! But since the problem will never be solved, we might as well
just accept that Internet anonymity causes temporary brain damage in
some people, and we should pity those so afflicted rather than let them
upset us ;-)

 

[Austin Ziegler]

Note that your lawyer might disagree with you, whether he is a GNU
fanboy or not, because it is widely agreed that the OpenSSL license is
incompatible with the GPL.

I agree that this sucks, but hey, that's life.

I see it the other way around; because the GNU GPL does not permit
attribution requirements, it is the GNU GPL which is incompatible with
the (older) BSD-style license. I agree that it'd be nicer if OpenSSL
and SSLeay were under the 3-clause BSD, but I understand exactly why
they do it.

To me, the 4+-clause BSD is far more acceptable than any GNU GPL
license, even the GNU LGPL, even v2 (which I think is an infinitely
superior license to v3, but that's just my opinion).

Lawyers will agree that there's a distribution incompatibility since
the GNU GPL doesn't permit attribution requirements and OpenSSL
requires it under two different licences. That is the key point, but
the FSF has already pointed a way out of this: write to a common API
that can be used transparently and allow end users (who are not
subject to redistribution requirements in any case) to swap out their
preferred implementation.

This is exactly what the FSF says should be done to deal with their
(likely incorrect) understanding of shared object linking especially
with respect to libreadline.

Since Ruby programmers and the Ruby language have no problem as such
with OpenSSL, I would suggest that it is up to GNU TLS supporters to
write that transparent layer and convince Rubyists to use it. GNU TLS
has a fraction of the users over OpenSSL.

-austin
--=20
Austin Ziegler =95 (e-mail address removed) =95 (e-mail address removed)
http://www.halostatue.ca/ =95 http://twitter.com/halostatue

 

[Aldric Giacomoni]

Note there are not many development communities that are proud of the
fact of having different, incompatible versions of the same software
being widely used at the same time.

Because Ruby is growing and moving quite fast at the moment. When it
slows down, there will be a major change in the general attitude of the
community regarding breaking code. Still, a young API can and most
likely should change. We all respect that - but now that's beside the
point.

Most other communities solve that by having more stable APIs and making
sure that their important software supports the latest API. Again.. Growing community ;-)

In Debian Squeeze (next Debian release), we ship (and support for
several years) ruby 1.8 (likely 1.8.249+some backports) and ruby 1.9.1
(maybe a prerelease of 1.9.2, but unlikely). It would be totally insane,
to, additionally, try to support several versions of the same libraries.
Of course, if you want to install many different Ruby and gems versions,
and then try to keep them in a sensible state wrt security issues (which
are not that uncommon in the ruby world), that's your choice.

Sorry to be a pain for you maintainers. Switch to Gentoo ;-) It handles
all that very well, and has done a fantastic job of handling an overlay
tree for gems - you can essentially get the gems installed and supported
by your distribution. It is of course far from perfect, but they're
doing a fine job of it.
Then again, they have just recently started handling license acceptance
for things like Java, VMWare and such, so Debian is eons ahead of them
in that regard -- which is in fact at the core of our current debate.

It's really to give the benefit of the doubt about civility to several
people on this list.

Normal person + Anonymity + Audience = Total fscktard. It's a
penny-arcade rule, and it's true. May as well be called "The Law of Gabe
& Tyco", or whatever their names are.
For whatever it's worth, Lucas, I have tremendous respect for the work
you do as a package maintainer. It's hard, time-consuming, sometimes
tedious, and sadly most of the time very thankless, as it is completely
behind the scenes.

Besides the issue of licensing mentioned above, the only other real
issue mentioned in this thread is "What will the users think?" or WWUT,
which can clearly be brought back to WWJDIHHAC (What would Jesus do if
he had a computer). JEG II made a change on Ruby's website to help
educating the users. Is it possible to add a message of some sort to the
pre-install apt-get warning when installing Ruby, to explain the
different Ruby packages?
I know it's not exactly Standard Operating Procedure for Debian, but
again, Ruby moves very fast, much faster than Debian does - which is not
a qualification, just a comparison.

 

[Austin Ziegler]

Apparently, the ruby core team is OK with the current situation, since
apt-get install ruby1.9.1-full/ruby-full is advertised on
http://www.ruby-lang.org/en/downloads/. You might want to educate your
users to read the documentation.

Also, I disagree that it's not our call to make. Most of the software
shipped by Debian is split in seperate packages, and Ruby is the only
case where I hear people complaining about such a minor issue.

(Also note that the split predates me being involved in Ruby
maintenance.)

Yes, it is. Let me be very clear in saying that the situation in the
last two years is, while far from ideal, significantly better than it
used to be. For that, let me say thank you. I disagree with you on a
number of things (including the fact that I think that Debian still
has a long way to go toward getting it right), but your maintenance is
appreciated and things are better than they used to be.

If, maybe, the Ruby community fixed the fact that it's illegal to load
all of stdlib in the same process (because of OpenSSL vs GPL), we could
consider including ssl and readline in the default lib pkg. However, I do= n't
see how we will make Ruby depend on installing Tcl/Tk (because of the TK
bindings), or Emacs (because of the ruby mode for emacs). Note that even
ruby-full doesn't install the TK and elisp stuff.

Please don't repeat this, because as I pointed out on ruby-core, it's
not true. it's not illegal to load libreadline and openssl in the same
process; it's illegal to ship software that contains both. Neither the
OpenSSL license nor the GNU GPL address use or incidental in-memory
copies, only distribution.

-austin
--=20
Austin Ziegler =95 (e-mail address removed) =95 (e-mail address removed)
http://www.halostatue.ca/ =95 http://twitter.com/halostatue

 

[Seebs]

Please don't repeat this, because as I pointed out on ruby-core, it's
not true. it's not illegal to load libreadline and openssl in the same
process; it's illegal to ship software that contains both. Neither the
OpenSSL license nor the GNU GPL address use or incidental in-memory
copies, only distribution.

The issue is, historically, that the FSF has claimed that a program
written to use the libreadline API is thereby a "derivative work" of
libreadline. A while back, they were arguing that the only way this
would be untrue would be if someone were to create a call-compatible
"readline" implementation, so that code couldn't be shown to be
unable to work without libreadline.

Which is funny, because I know of at least one such implementation dating
back to 1992. Rich $alz posted it, with these terms:

X Permission is granted to anyone to use this software for any purpose on
X any computer system, and to alter it and redistribute it freely, subject
X to the following restrictions:
X 1. The authors are not responsible for the consequences of use of this
X software, no matter how awful, even if they arise from flaws in it.
X 2. The origin of this software must not be misrepresented, either by
X explicit claim or by omission. Since few users ever read sources,
X credits must appear in the documentation.
X 3. Altered versions must be plainly marked as such, and must not be
X misrepresented as being the original software. Since few users
X ever read sources, credits must appear in the documentation.
X 4. This notice may not be removed or altered.

(Yes, it was a shar script.)

Long story short: There hasn't been a problem with stuff merely designed
to work with readline or something compatible with it since 1992 or possibly
earlier.

-s

 

[Lucas Nussbaum]

Sorry to be a pain for you maintainers. Switch to Gentoo ;-) It handles
all that very well, and has done a fantastic job of handling an overlay
tree for gems - you can essentially get the gems installed and supported
by your distribution. It is of course far from perfect, but they're
doing a fine job of it.
Then again, they have just recently started handling license acceptance
for things like Java, VMWare and such, so Debian is eons ahead of them
in that regard -- which is in fact at the core of our current debate.

I think that rubygems and emerge and actually quite similar, which
probably explains why they work together well. Rubygems is a great tool
for developers who want to get the latest cutting edge software.
However, at some point, applications are transferred from developers to
sysadmins, and "cutting edge" isn't really a good selling point.
Internally (in an organization) it's fine, because you can just
vendorize all the gems you use. But if you want to distribute your
application to the outside world, it's difficult to explain that the
user needs to use rubygems to install that application because it's
written in ruby, while the ruby is just interested in the functionality
provided by the application, and doesn't care whether it's perl or ruby.

I think that approaches that aim at getting rubygems and apt-get to
cooperate are just wrong. Both rubygems and apt-get have good reasons to
exist, but they don't solve the same problem. Instead, we should try to
develop a set of good practices that make it easier to convert a ruby
library into a "normal" Deb or RPM package. Much progress has already
been done lately, and the last libraries I've packaged didn't use
"require 'rubygems'" except in the test suite, so they did not require
any patching.

We are currently trying to finish the releases for Ubuntu Lucid and
Debian Squeeze (in order of appearance . After that, it is likely that
the way we package ruby libraries in Debian will be discussed with the
goal to make it easier to support both ruby 1.8 and 1.9.X (I don't see
Ruby 1.8 disappearing during the next 2.5 years). This discussion will
also be a good opportunity to discuss other aspects of Ruby packaging.

Besides the issue of licensing mentioned above, the only other real
issue mentioned in this thread is "What will the users think?" or WWUT,
which can clearly be brought back to WWJDIHHAC (What would Jesus do if
he had a computer). JEG II made a change on Ruby's website to help
educating the users. Is it possible to add a message of some sort to the
pre-install apt-get warning when installing Ruby, to explain the
different Ruby packages?

I have kind-of done that a few hours ago.

Before:
# apt-get install ruby
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libruby1.8 ruby1.8
Suggested packages:
ruby1.8-examples rdoc1.8 ri1.8
The following NEW packages will be installed:
libruby1.8 ruby ruby1.8
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 2041kB of archives.
After this operation, 6644kB of additional disk space will be used.

Now:
# apt-get install ruby
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libruby1.8 ruby1.8
Suggested packages:
irb rdoc ri libopenssl-ruby ruby-dev ruby1.8-examples rdoc1.8 ri1.8
The following NEW packages will be installed:
libruby1.8 ruby ruby1.8
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 2060kB/2082kB of archives.
After this operation, 6980kB of additional disk space will be used.

(See the list of Suggested packages)

It's not much, but still a slight improvement, which should probably
have been done before.