I take your point: Ruby has made decisions that make it hard to install end-user applications (what few there are) without bundling up an entire additional Ruby universe. Ruby - community - Ruby doesn't work for end-user applications that want to depend on a single system Ruby. Yes. This is true. I get it.
But the actions Debian took to try to fix that situation broke Ruby for Ruby's real users, which are developers. You say that nothing Debian could have done would change things for developers, but that's not true; you presume that, had Debian not undertaken it's strange neutering of RubyGems, Ruby devs would still have to rebuild the universe to deploy there. No. I don't do that on OS X. I only have to do it on Debian, because Debian was wrong about Ruby.
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.
Some of the problems that Debian has had have been simply due to lack of manpower. AFAICT, they could have made `gem update --system` work, but that would have taken a lot of time they didn't have, so they disabled it.
And it's a thankless task. There's no way that Debian would ever compromise on anything, the Ruby community is not interested in removing features from RubyGems to accomodate Debian, and the developers are caught in the middle, being blamed for problems caused by policies they have no control over.
So of course, nobody wants to volunteer to help.
That's why when they get attacked (like I saw you doing), I jump in to defend them.
There is hope for the future -- Bundler and RVM make many of the "features" of RubyGems obsolete, IMO.
But I still disagree with your statement that Ruby's real users are developers. End users are the whole point of developers. Without end users, developers are just masturbating. It's fun, but it doesn't get anywhere.
> There is hope for the future -- Bundler and RVM make many of the "features" of RubyGems obsolete, IMO.
What? Bundler uses RubyGems! Why do you think Gemfile is called Gemfile?
I think we're talking about two different aspects of RubyGems here:
1. The "gem install" command.
2. The RubyGems database and gem activation code.
Bundler merely replaces the first part. It uses the second part at its core. Still, it makes no sense to me that you see Bundler as "hope". It installs the same gems, just to different places now, usually project-dependent spaces. This latter results in duplication and I thought that was one of the things that Debian people despise.
> But I still disagree with your statement that Ruby's real users are developers. End users are the whole point of developers. Without end users, developers are just masturbating. It's fun, but it doesn't get anywhere.
The end users are the people using the web apps. And they don't install anything.
Even if we define "end users" as "people using Ruby apps", or to take a concrete example, "Redmine users", Debian's current packaging is still next to useless. It forces users to install their own Ruby from source just to make any modern Ruby app working.
I take your point: Ruby has made decisions that make it hard to install end-user applications (what few there are) without bundling up an entire additional Ruby universe. Ruby - community - Ruby doesn't work for end-user applications that want to depend on a single system Ruby. Yes. This is true. I get it.
But the actions Debian took to try to fix that situation broke Ruby for Ruby's real users, which are developers. You say that nothing Debian could have done would change things for developers, but that's not true; you presume that, had Debian not undertaken it's strange neutering of RubyGems, Ruby devs would still have to rebuild the universe to deploy there. No. I don't do that on OS X. I only have to do it on Debian, because Debian was wrong about Ruby.