The statement "Ruby's real users" is telling. Ruby's real users include everyone downstream using Ruby applications: web apps, gems, tools, stand-alone apps. Some compromise needs to be made to suit all parties. Thus far it seems to me that the Debian world has been trying to make it work whilst a lot of Rubyists throw rocks from the sidelines. YMMV.
Yes, this is clearly what the Debian people think. But you aren't engaging with the argument, you're just hissing at it.
Again: I didn't just say "Ruby's real users are people who think like I do". I said "Ruby is used by significantly more developers than by end-users and should be optimized for its most important use case". You can disagree with that, but the onus is on your to support your argument with evidence.
Instead, you've attempted to personalize the argument. Try again.
This. From what I've seen of the entire Debian-Ruby fiasco, your post accurately describes how Debian people talk past all the people who are complaining about Ruby on Debian.
Ruby targets developers. I think that's wrong, but let's say you're right. It still doesn't matter. Debian targets end users. If you want a distribution that doesn't target end users, use a different distribution, like Gentoo.
But Debian is one of the best distributions because of the way it targets end users and because it never compromises.
The thing you're missing here is the privileged place "/usr/bin" has on the filesystem. It is reasonable and proper for a package to expect to install a real, unadulterated version of itself in the standard user path. You can't simply say "well, developers can just install their own version" while at the same time installing a broken version of Ruby in the standard path.
The right call would have been not to package Ruby at all.
I think it may even be true that distribution maintainers should look at installing the scripting languages their OS requires in different privileged places and version-locking their system scripts, as upgrading Python from 2.4 to 2.7 can break some system scripts, yet useful tools like Mercurial don't like very old versions of Python.
Au contraire: the Debian world has crippled RubyGems, which focusses on making Ruby packaging work everywhere, while Apple made modifications that made it work as Rubyists expect without causing problems for Apple's own needs. Eric Hodel modified this to make it easier for Linux distro maintainers to allow RubyGems to work as Rubyists expect yet not break the distro's expectations. The Debian maintainers chose not to adopt this. I don't use other distros, so I don't know whether they did or not.
What I've never personally understood is why the distro maintainers didn't embrace RubyGems. There's no reason that a .deb couldn't simply wrap a .gem and use the RubyGems infrastructure to install it into a "protected" area (preventing 'gem remove' from working, per the modifications noted above). A .gem can even be a repackaged version that includes platform-specific compiled code so that it could be distributed to machines without compilers (this is one thing that could be improved for RubyGems; allowing users to gemify a built gem for deployment purposes). I've suggested this in the past and it's been met with derision from OS maintainers. I don't understand why: as I understand it, this is what happens with BSD ports of gems.
So no, the Ruby community hasn't thrown rocks from the sidelines. We've made constructive suggestions that have been derided or ignored; so ignored, we've made our own solutions that work well for our needs.
