Re: [gentoo-user] Ruby - 3 versions - seriously????

[konsolebox]

On Tue, Sep 5, 2017 at 4:32 AM, Marvin Gülker  wrote:
> Real breaking
> changes of documented behaviour like the Bignum/Fixnum one are rare, and
> the effects are moderate.

This isn't even "breaking" yet. Only deprecated.

-- 
konsolebox

Re: [gentoo-user] Ruby - 3 versions - seriously????

[R0b0t1]

Sorry, I missed your reply.

On Mon, Sep 4, 2017 at 3:32 PM, Marvin Gülker  wrote:
> Am 04. September 2017 um 12:07 Uhr -0500 schrieb R0b0t1 :
>> Even if they can not present an argument like I have,
>> they will probably only notice it if it misbehaves in some way. If it
>> misbehaves more than other software on their system, who is to say it
>> isn't a poorly designed language and/or ecosystem?
>
> I think that on a technical mailinglist you should convey your point
> using technical arguments, not rhethorical ones.

The technical reasoning in the argument I presented is "it doesn't
work when I try to use it." It is not sophistry.

> The reasoning is
> errorneous. If your goal is not ultimate API stability, then Ruby's
> design approach that focuses more on progress than on ultimate API
> stability is not poor, but different. You can agree or disagree with the
> goal, but you can't question the measures taken to implement it by first
> stipulating a goal different from the one the measure was intended to
> implement. Take a look at Ruby's versioning policy[1]; ultimate API
> backward compatibility is not a design goal in minor versions of the
> language. Ruby is simply not the right tool for the job if you want to
> create for example an archive software that must run 20 years without
> touching it.
>

The problem is there's a zeroth goal of every project: to be useful.
If the software produced is hard to use or not usable at all, then all
of the work spent on it is for naught.

Suggesting that it is impossible to progress a language while
maintaining language stability is fallacious reasoning. You can choose
to do both, e.g. by structuring releases so that breaking changes are
lumped together, as in Python. It is also the case that not all
changes are good changes, though experimentation is key to success.

> Even though, the problem is not as dramatic as you seem to imply. I
> stand by my point that using private C interfaces is the programmer's
> fault and there is nothing to be standardised here. Real breaking
> changes of documented behaviour like the Bignum/Fixnum one are rare, and
> the effects are moderate. Most of the software written in Ruby will not
> have a problem with running on newer versions.
>

The problem is dramatic enough if there's people complaining about it.
Granted, most distributions seem to take care of such issues for their
users, so the only people complaining seem to be Gentooers.

Other people who do not like the situation simply avoid Ruby.

Cheers,
 R0b0t1.

Re: [gentoo-user] Ruby - 3 versions - seriously????

[R0b0t1]

On Mon, Sep 4, 2017 at 12:49 PM, Michael Orlitzky  wrote:
> On 09/04/2017 01:07 PM, R0b0t1 wrote:
>>
>> For almost all languages but Ruby (and Perl) you can take code written
>> against one minor version and compile it in the next minor version.
>
>
> This isn't a language issue with Ruby, it's a culture/package-management
> one. For a long time, it's been easy to bundle dependencies in Ruby. The
> result is a culture of saying "I need the version of ruby-foo that was
> released on my birthday that one time mercury was in retrograde, and
> also I'd like the version number to have a seven in it somewhere because
> that's my daughter's age." When two package authors come up with two
> different requirements like that, you end up needing *two* versions of
> ruby-foo installed.
>

That's very insightful. However, I think developers originally started
requesting versions with such specificity because breaking changes,
even minor ones, were made with such consistency. At a certain point
this does simply spill over into maintainer preference but package
maintainers may be following the lead of the language developers.

E.g. most Python packages provide extremely stable interfaces.

Cheers,
 R0b0t1.

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Marvin Gülker]

Am 04. September 2017 um 12:07 Uhr -0500 schrieb R0b0t1 :
> Even if they can not present an argument like I have,
> they will probably only notice it if it misbehaves in some way. If it
> misbehaves more than other software on their system, who is to say it
> isn't a poorly designed language and/or ecosystem?

I think that on a technical mailinglist you should convey your point
using technical arguments, not rhethorical ones. The reasoning is
errorneous. If your goal is not ultimate API stability, then Ruby's
design approach that focuses more on progress than on ultimate API
stability is not poor, but different. You can agree or disagree with the
goal, but you can't question the measures taken to implement it by first
stipulating a goal different from the one the measure was intended to
implement. Take a look at Ruby's versioning policy[1]; ultimate API
backward compatibility is not a design goal in minor versions of the
language. Ruby is simply not the right tool for the job if you want to
create for example an archive software that must run 20 years without
touching it.

Even though, the problem is not as dramatic as you seem to imply. I
stand by my point that using private C interfaces is the programmer's
fault and there is nothing to be standardised here. Real breaking
changes of documented behaviour like the Bignum/Fixnum one are rare, and
the effects are moderate. Most of the software written in Ruby will not
have a problem with running on newer versions.

Marvin

[1]: 
https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-policy-changes-with-2-1-0/

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Michael Orlitzky]

On 09/04/2017 01:07 PM, R0b0t1 wrote:
> 
> For almost all languages but Ruby (and Perl) you can take code written
> against one minor version and compile it in the next minor version.


This isn't a language issue with Ruby, it's a culture/package-management
one. For a long time, it's been easy to bundle dependencies in Ruby. The
result is a culture of saying "I need the version of ruby-foo that was
released on my birthday that one time mercury was in retrograde, and
also I'd like the version number to have a seven in it somewhere because
that's my daughter's age." When two package authors come up with two
different requirements like that, you end up needing *two* versions of
ruby-foo installed.

Even if both packages could happily use the same, latest version of
ruby-foo -- you get what upstream says in most cases. And what upstream
says is usually crap, because they bundle everything and will never
notice annoying incompatibilities like end-users do.

Re: [gentoo-user] Ruby - 3 versions - seriously????

[R0b0t1]

On Mon, Sep 4, 2017 at 1:49 AM, Marvin Gülker  wrote:
> Am 03. September 2017 um 15:35 Uhr -0500 schrieb R0b0t1 :
>> I think the takeaway from Alan's comment is that Python is unnaturally
>> stable compared to other interpreted languages. One might be inclined
>> to think Python developers consider their work to be a widely used
>> tool as opposed to a toy to play with.
>
> If you regard Ruby as a toy language, I'm inclined to say that quite a
> number of (most often Rails) applications use it in for serious
> projects.
>

I don't doubt they're attempting to be serious.

>> These are all fairly major changes for a minor release. I'm not really
>> sure any of this evidence supports the opinion that Ruby doesn't
>> experience breaking changes more regularly than other languages.
>
> I have not made the claim that Ruby is more stable than other languages,
> especially did I never say that Ruby is as stable as Python. My
> intention was the counter the statement that every Ruby minor release is
> a "complete new language". The changes I listed are breaking, but not to
> a degree that justifies the "complete new language" statement.
>

For almost all languages but Ruby (and Perl) you can take code written
against one minor version and compile it in the next minor version. I
don't disagree that the language at large is more or less the exact
same thing, but there is enough different to prevent a program from
compiling - thus, it's a new language.

>> Situations like the above, and reliance on private C interfaces, are
>> what makes it seem plausible to me that there are packages that
>> require a version that has no listed breaking changes.
>
> Using unsupported private C interfaces is going to make any package
> break in any language over time. This is not Ruby's fault.
>

Perhaps not in the technical sense, but there is software written
against those interfaces and people use it. Perhaps those interfaces
should be standardized?

>> This statement makes me think you haven't tried to understand the
>> issue, as that ISO document - to the best of my knowledge, I can't
>> actually view it without paying money - implements Ruby 1.8.1 and
>> potentially some features from 1.9. Hearsay indicates it was started
>> at the behest of the Japanese government so that they could use Ruby
>> for internal projects as their rules seem to require standards
>> documents for software. This is important, because it shows that there
>> is no real effort by Ruby's lead developer or the Ruby community to
>> produce a legitimate standards document.
>
> I've not worked with the ISO document. You requested a formal standard,
> and I replied that there's an ISO document, which I regard as a
> standard. I didn't know that it describes such an ages old version of
> Ruby (though I should have known better given the date). Since the 2.4.0
> release post on ruby-lang.org justifies removal of Fixnum/Bignum with
> the interpreter not being compliant with the ISO standard, I was under
> the impression that it was still usable. If it isn't, I apologise.
>

You can still use it, but it only defines Ruby ~1.8. To most that
means it is not usable. I'm not certain why they bothered to quote it
for justification. Grasping at straws?

Standards can exist and still be useless. That the standard would be
so vague as to not guarantee any interoperability between vendors was
something that some users feared when it was still relevant.

>> In practice one finds more references to something called RubySpec
>> which is an executable implementation of what people like to call a
>> specification. RubySpec appears to be discontinued[1], but even when
>> it was in use there are three things that should be pointed out:
>
> The RubySpec was started as a community effort indeed, but if you only
> read the Rubinius view of it, you're going to see a lot of bias. The
> Rubinius main maintainer retracted from the effort by his own
> decision. Consequently, the RubySpec is now maintained by the core team
> of the canonical Ruby implementation[1]. Thus, it is not true that the
> core developers do not make use of RubySpec.
>

This is sufficiently new that I hadn't learned of it. Still though,
there is more than one Ruby implementation, and past behavior w.r.t.
creating a language specification has me dubious that the
specification will be maintained to a useful degree.

The issue in the past when RubySpec was a separate project was that
everyone seems to have ended up ignoring it, because writing testcases
is no fun. Unless there are strictly enforced project guidelines I
don't expect the existence of ruby/spec to mean anything more than the
existence of RubySpec.

And, again, there are still crucial areas of the language left
undefined, namely its grammar.

>> If you look at the RubySpec code you will see that the "specification"
>> consists of testcases that attempt to define the behavior of Ruby. As
>> mentioned, these tests 

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Marvin Gülker]

Am 03. September 2017 um 15:35 Uhr -0500 schrieb R0b0t1 :
> I think the takeaway from Alan's comment is that Python is unnaturally
> stable compared to other interpreted languages. One might be inclined
> to think Python developers consider their work to be a widely used
> tool as opposed to a toy to play with.

If you regard Ruby as a toy language, I'm inclined to say that quite a
number of (most often Rails) applications use it in for serious
projects.

> Then why does he have all three installed?

I cannot answer that. I lack the insight into the Gentoo Ruby deployment
process.

> These are all fairly major changes for a minor release. I'm not really
> sure any of this evidence supports the opinion that Ruby doesn't
> experience breaking changes more regularly than other languages.

I have not made the claim that Ruby is more stable than other languages,
especially did I never say that Ruby is as stable as Python. My
intention was the counter the statement that every Ruby minor release is
a "complete new language". The changes I listed are breaking, but not to
a degree that justifies the "complete new language" statement.

> Leading into my next point, I remember some conversations about people
> discussing the Ruby parser and how there was no BNF description of the
> language. Consequently (from memory) there was at least one
> implementation of Ruby were encountering regressions in the parser
> between versions that were undocumented and not detected until the
> releases had already been made. The result was that code was
> semantically different between some versions. Regrettably I'm having
> trouble citing this one.

It was JRuby as far as I know, but don't nail me on that. I don't have
it ready either, nor do I have the exact circumstances in memory.

> Situations like the above, and reliance on private C interfaces, are
> what makes it seem plausible to me that there are packages that
> require a version that has no listed breaking changes.

Using unsupported private C interfaces is going to make any package
break in any language over time. This is not Ruby's fault.

> This statement makes me think you haven't tried to understand the
> issue, as that ISO document - to the best of my knowledge, I can't
> actually view it without paying money - implements Ruby 1.8.1 and
> potentially some features from 1.9. Hearsay indicates it was started
> at the behest of the Japanese government so that they could use Ruby
> for internal projects as their rules seem to require standards
> documents for software. This is important, because it shows that there
> is no real effort by Ruby's lead developer or the Ruby community to
> produce a legitimate standards document.

I've not worked with the ISO document. You requested a formal standard,
and I replied that there's an ISO document, which I regard as a
standard. I didn't know that it describes such an ages old version of
Ruby (though I should have known better given the date). Since the 2.4.0
release post on ruby-lang.org justifies removal of Fixnum/Bignum with
the interpreter not being compliant with the ISO standard, I was under
the impression that it was still usable. If it isn't, I apologise.

> In practice one finds more references to something called RubySpec
> which is an executable implementation of what people like to call a
> specification. RubySpec appears to be discontinued[1], but even when
> it was in use there are three things that should be pointed out:

The RubySpec was started as a community effort indeed, but if you only
read the Rubinius view of it, you're going to see a lot of bias. The
Rubinius main maintainer retracted from the effort by his own
decision. Consequently, the RubySpec is now maintained by the core team
of the canonical Ruby implementation[1]. Thus, it is not true that the
core developers do not make use of RubySpec.

> If you look at the RubySpec code you will see that the "specification"
> consists of testcases that attempt to define the behavior of Ruby. As
> mentioned, these tests are written in Ruby, and are subject to bugs in
> Ruby that are made undetectable, or very hard to detect, by the
> self-referential relationship of the behavioral specification and the
> language.

This sounds logical to me, and I agree. I'm not the correct person to
address this to, though. From the formal point of view, I surely cannot
compete with you. The spirit in the Ruby development appears to follow
not a formal, but a practical approach, which is always going to be
inferior.

> What I have read in this regard leads me to conclude that Ruby is not
> a language that I should use for my development, and it pains me to
> say this.

Use the tool that fits the job for you. I wonder if I was perceived as
using Ruby everythere; this isn't the case. Actually, I don't write much
Ruby code currently, but much more C/C++.

Marvin

[1]: https://github.com/ruby/spec

Re: [gentoo-user] Ruby - 3 versions - seriously????

[R0b0t1]

On Sun, Sep 3, 2017 at 1:08 AM, Hans de Graaff  wrote:
> The situation with ruby really isn't different from python or perl at
> all. We also have multiple python versions in the tree just like with
> ruby. perl is not slotted but faces the same issues on each version (e.g.
> the "no . in INC path anymore" issue that made ruby 1.8 to 1.9 such a big
> deal).
>

I think the takeaway from Alan's comment is that Python is unnaturally
stable compared to other interpreted languages. One might be inclined
to think Python developers consider their work to be a widely used
tool as opposed to a toy to play with.

Consequently the number of breaking changes does seem to be far higher
in Ruby. Please see my reply to Marvin below.

> I find it very unlikely that you would *need* all three versions, unless
> you are doing ruby development and want to actively use all three. The
> RUBY_TARGETS="ruby22" advice matches the current default in the profile.
>

Then why does he have all three installed?


On Sun, Sep 3, 2017 at 5:31 AM, Marvin Gülker  wrote:
> Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 :
>> Seeing as the OP is saying there are 3 versions queued for merge and
>> he has not installed any of them by hand it looks like Alan is
>> right. Perhaps the OP is using "old" Ruby based software, but software
>> of that age in another language could work on new interpreters.
>
> I took a moment and looked up the release announcements for the minor
> version releases between the versions the OP has installed:
>
> * https://www.ruby-lang.org/en/news/2015/12/25/ruby-2-3-0-released/
> * https://www.ruby-lang.org/en/news/2016/12/25/ruby-2-4-0-released/
>
> 2.4.0 saw breaking changes, 2.3.0 not. In 2.4.0, the most notable
> breaking change was the unification of Fixnum and Bignum into
> Integer. Other breaking changes affected the standard library (stdlib):
>
> * Tk was dropped from the stdlib.
> * XMLRPC was dropped from the stdlib.
> * Support for OpenSSL <= 0.9.7 was dropped from the stdlib.
>
> For Tk specifically, the reason for the removal was that the maintainer
> got demotivated by useless and even hostile feedback[1] and since nobody
> wanted step up, the library was removed from the stdlib[2].
>
> The exact judgement of how grave these changes are is subjective. Fixnum
> and Bignum were not classes commonly used in Ruby code, so it may be
> viewed as a detail. They saw a more frequent use in C extensions, which
> may then be viewed more grave; the release announcement iself is pretty
> clear on this topic:
>
> Ruby 2.4.0 release announcment from 2016-12-25:
>> All C extensions which touch the Fixnum or Bignum class need to be
>> fixed.
>
> I was not too happy with this either, but most software continued to
> work.
>

These are all fairly major changes for a minor release. I'm not really
sure any of this evidence supports the opinion that Ruby doesn't
experience breaking changes more regularly than other languages. E.g.
Python doesn't see name changes or standard class removals in minor
versions. There has only been one major set of breaking change to
date, Python 2 to Python 3, and it seems like the Python developers
will continue

> I don't know the reason why the OP was left with three versions of
> Ruby. Given the above release announcements, there are not too many
> reasons why his software should not work with newer versions of
> Ruby.
>
> All this only applies to the core language. Some RubyGems packages
> release very rigorously and some even make use of undocumented features
> of (the C interface of) the Ruby language. That's however a different
> problem.
>

Leading into my next point, I remember some conversations about people
discussing the Ruby parser and how there was no BNF description of the
language. Consequently (from memory) there was at least one
implementation of Ruby were encountering regressions in the parser
between versions that were undocumented and not detected until the
releases had already been made. The result was that code was
semantically different between some versions. Regrettably I'm having
trouble citing this one.

Situations like the above, and reliance on private C interfaces, are
what makes it seem plausible to me that there are packages that
require a version that has no listed breaking changes. I admit I have
not looked in great detail because I do not have the time.

> Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 :
>> One of the reasons I dislike Ruby is that there is no complete
>> specification of the language available, making this statement
>> (technically) untestable.
>
> There *is* a formal complete ISO specification of the language available,
> approved in 2012[3].
>

This statement makes me think you haven't tried to understand the
issue, as that ISO document - to the best of my knowledge, I can't
actually view it without paying money - implements Ruby 1.8.1 and

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Marvin Gülker]

Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 :
> Seeing as the OP is saying there are 3 versions queued for merge and
> he has not installed any of them by hand it looks like Alan is
> right. Perhaps the OP is using "old" Ruby based software, but software
> of that age in another language could work on new interpreters.

I took a moment and looked up the release announcements for the minor
version releases between the versions the OP has installed:

* https://www.ruby-lang.org/en/news/2015/12/25/ruby-2-3-0-released/
* https://www.ruby-lang.org/en/news/2016/12/25/ruby-2-4-0-released/

2.4.0 saw breaking changes, 2.3.0 not. In 2.4.0, the most notable
breaking change was the unification of Fixnum and Bignum into
Integer. Other breaking changes affected the standard library (stdlib):

* Tk was dropped from the stdlib.
* XMLRPC was dropped from the stdlib.
* Support for OpenSSL <= 0.9.7 was dropped from the stdlib.

For Tk specifically, the reason for the removal was that the maintainer
got demotivated by useless and even hostile feedback[1] and since nobody
wanted step up, the library was removed from the stdlib[2].

The exact judgement of how grave these changes are is subjective. Fixnum
and Bignum were not classes commonly used in Ruby code, so it may be
viewed as a detail. They saw a more frequent use in C extensions, which
may then be viewed more grave; the release announcement iself is pretty
clear on this topic:

Ruby 2.4.0 release announcment from 2016-12-25:
> All C extensions which touch the Fixnum or Bignum class need to be
> fixed.

I was not too happy with this either, but most software continued to
work.

I don't know the reason why the OP was left with three versions of
Ruby. Given the above release announcements, there are not too many
reasons why his software should not work with newer versions of
Ruby.

All this only applies to the core language. Some RubyGems packages
release very rigorously and some even make use of undocumented features
of (the C interface of) the Ruby language. That's however a different
problem.

Am 02. September 2017 um 21:18 Uhr -0500 schrieb R0b0t1 :
> One of the reasons I dislike Ruby is that there is no complete
> specification of the language available, making this statement
> (technically) untestable.

There *is* a formal complete ISO specification of the language available,
approved in 2012[3].

Marvin

[1]: Exact reasoning of the maintainer is here (in reply to me):
 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/436401
[2]: https://bugs.ruby-lang.org/issues/8539
[3]: https://www.iso.org/standard/59579.html

Re: [gentoo-user] Ruby - 3 versions - seriously????

[R0b0t1]

On Sat, Sep 2, 2017 at 4:37 PM, Marvin Gülker  wrote:
> Am 02. September 2017 um 22:57 Uhr +0200 schrieb Alan McKinnon 
> :
>> OK, so disclaimer up front. I detest Ruby. I hate it with a passion.
>
> There is nothing one can do against that, but...
>
>> Each new minor version of ruby is a whole new language and the devs
>> are OK with large breaking changes between minor version numbers.
>
> ...this is factually incorrect. There are new features added quite
> often, but minor versions are generally backwards-compatible. The one
> exception was the 1.8->1.9 switch years ago.

One of the reasons I dislike Ruby is that there is no complete
specification of the language available, making this statement
(technically) untestable. Seeing as the OP is saying there are 3
versions queued for merge and he has not installed any of them by hand
it looks like Alan is right. Perhaps the OP is using "old" Ruby based
software, but software of that age in another language could work on
new interpreters.

Cheers,
 R0b0t1.

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Marvin Gülker]

Am 02. September 2017 um 22:57 Uhr +0200 schrieb Alan McKinnon 
:
> OK, so disclaimer up front. I detest Ruby. I hate it with a passion.

There is nothing one can do against that, but...

> Each new minor version of ruby is a whole new language and the devs
> are OK with large breaking changes between minor version numbers.

...this is factually incorrect. There are new features added quite
often, but minor versions are generally backwards-compatible. The one
exception was the 1.8->1.9 switch years ago. I have done quite a bit of
web developing with it and never had an API break problem with Ruby
itself, save the aforementioned 1.8/1.9 switch.

Granted, gems are quite different. RubyOnRails especially releases new
(breaking) versions way too fast for me; that's why I prefer to use
different libraries.

Marvin

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Alan McKinnon]

On 02/09/2017 15:33, Andrew Lowe wrote:
> Hi all,
>   I'm in the process of doing a world update and due to a failed compile,
> I have cause to look up through the list of stuff to compile/update.
> Imagine my surprise when I saw there were three versions of Ruby wanting
> to update:
> 
> [ebuild U  ] dev-lang/ruby-2.4.1-r4 [2.4.1-r3]
> [ebuild U  ] dev-lang/ruby-2.3.4-r4 [2.3.4-r3]
> [ebuild U  ] dev-lang/ruby-2.2.7-r4 [2.2.7-r3]
> 
> Have I managed to stuff up something on my machine or is this really the
> case, there has to be three versions? And to make matters worse, they
> are not big version jumps, + 0.1 -> 2.2, 2.3 & 2.4.
> 
>   I would prefer to get rid of Ruby, but, if memory serves me correctly,
> someone associated with the kernel decided it would be a good idea to
> use yet another language for something, obviously Python wasn't good
> enough
> 
>   Thoughts on the magically multiplying Rubies would be greatly 
> appreciated,


Welcome to the giant clusterfuck that is RubyWorld(tm). Just be thankful
you don't have to support corporate internal code written in it. Or
package gems.

OK, so disclaimer up front. I detest Ruby. I hate it with a passion.

You have to understand what Ruby is. It is not a language. It is 5
languages. Like python27 and python3 are really different languages with
much in common. The difference is the python devs have solid reasons for
doing python3 and the transition has been mostly smooth. Each new minor
version of ruby is a whole new language and the devs are OK with large
breaking changes between minor version numbers.

So why 3 rubys? Because they are 3 languages and you have packages that
for whatever reason are tied to different rubys. Just pretend to
yourself that they aren't really ruby22, ruby23 and ruby24 - they are
php, perl and python (or whatever 3 language names you like that help
you get past the 3 rubys! thing).

You probably need all 3. As housekeeping, you can put this in make.conf:
RUBY_TARGETS="ruby22",
and remove all ruby versions from world
and let depclean, revdep-rebuild and emerge world take care of the details.

-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Ruby - 3 versions - seriously????

[Peter Humphrey]

On Saturday, 2 September 2017 14:33:31 BST Andrew Lowe wrote:

> I'm in the process of doing a world update and due to a failed compile,
> I have cause to look up through the list of stuff to compile/update.
> Imagine my surprise when I saw there were three versions of Ruby wanting
> to update:
> 
> [ebuild U  ] dev-lang/ruby-2.4.1-r4 [2.4.1-r3]
> [ebuild U  ] dev-lang/ruby-2.3.4-r4 [2.3.4-r3]
> [ebuild U  ] dev-lang/ruby-2.2.7-r4 [2.2.7-r3]
> 
> Have I managed to stuff up something on my machine or is this really the
> case, there has to be three versions? And to make matters worse, they
> are not big version jumps, + 0.1 -> 2.2, 2.3 & 2.4.
> 
> I would prefer to get rid of Ruby, but, if memory serves me correctly,
> someone associated with the kernel decided it would be a good idea to
> use yet another language for something, obviously Python wasn't good
> enough
> 
> Thoughts on the magically multiplying Rubies would be greatly
> appreciated,
> 
>   Andrew

Won't portage let you remove any of them? On my system only qtwebkit and 
webkit-gtk need ruby, and they seem happy to accept version 2.2.6. Nothing 
apparently to do with the kernel.

-- 
Regards,
Peter.