That argument would make sense if RubyGems was actually useful on OS X or Windows. But every single application targeted at "normal users" on Windows or OSX written in Ruby bundles all dependencies, usually even including Ruby itself.

RubyGems needs to REMOVE harmful features, like the ability to install multiple minor versions of the same gem. Developers should be using RVM to get this capability.

The ability to install multiple versions of the same gem are pretty much key to the migration path of any ruby app. Just because it doesn't fit in the package manager world of some (read: all) distributions is not the fault of Ruby.

I can't count the number of times that we rolled out (while I was at the AJC) a new version of one of our apps on a different version of rails while keeping the other apps collocated on the same box running the previous version.

The lack of support for multiple installed versions of the same package is a major failure of dpkg and rpm.

Have a look at NixOS for a different approach to the problem.

I developed PDF::Writer entirely on Windows and used RubyGems extensively. With the new Ruby Installer work by Luis Lavena and others, RubyGems is now amazingly awesome on Windows.

The Linuxes are the least-well represented and the least interested in working with RubyGems developers. There are hooks to make things work better: they were first offered by Apple and subsequently modified by Eric Hodel to be more generic so that Debian could benefit. They refused to use these vendor hooks.

You're right that apps that target "desktop" users bundle Ruby, but I remember a game from 2001 that bundled Python. This is no different. Apps need to control their dependencies (my company's backup app includes vendor-locked versions of OpenSSL in the program directory because we can't trust full compatibility without that)

Edited to add:

The RubyGems multiple version feature (which is one of the things that the Debian team seems to dislike) doesn't assign any meaning to version levels. The fact that 1.2.3 usually means "major version 1, minor version 2, patch version 3" is entirely social and of no meaning to RubyGems. The only thing that it cares about is that version A is comparably larger or smaller than version B. I could have version 1.2.3.4.5 and 1.3.5.7 and it would only care that the latter is larger (because the second level of the latter is larger than the second level of the former).

Removing this but keeping "top-level" versions would encourage people to rev their top-level versions more often. This may not be a bad thing, but it won't give you the effect you think it will.

Huh? OS X is my primary development platform, Debian is my primary deployment platform, and on both, I use a ruby from /usr/local/bin, and I type "bundle install" to get my deps working, and everything works fine.

But you're a web developer. Ruby works excellently for developers and for web apps.

Debian's primary concern is for end users, those who install applications via the pretty GUI. RubyGems made some choices that are very poor for these users.

The Ruby community has decided that these users are unimportant. And that's fair, there aren't many of them. "Fixing" RubyGems would not help developers, would not help web apps, would not help OS X or Windows end users, all of whom far outnumber Linux end users.

But recognize that this is a deliberate decision on the part of the Ruby community to ignore these users. But these Linux end users are Debian's raison d'etre, so recognize that the blame properly belongs on the shoulders of the Ruby community.

It may be a reasonable decision on the Ruby community's part, but it's still their "fault".

I feel like we may be talking past each other.

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.

Optimize for the largest audience!

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.

You can't eat your cake and have it too.

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.

Rubbish. Try to install a binary into a directory that isn't bin and then tell me about being better citizens.

Can you explain what this comment means? I literally don't understand what you're trying to say.

What I believe he is complaining about is the fact that there is no way to specify an alternative installation path for binaries outside of bin.

Now, I am not sure with one either way since I don't use Ruby, and am merely interpreting the sentence above.

RubyGems only allows the installation of binary files to bin. Lots of binary files should go into sbin. This is a serious limitation with packaging.

If the author of the package is fine with the binaries going into bin, why do you care?

So I am going to suggest you're a developer. I am, amongst other things, a packager. Lots of platforme mandate that certain types of binaries go in certain places. This isntpossible with gems. I find this very frustrating for the gems I maintain - including Puppet for example.

If FHS religion means you can't put something in bin(7) if it's an admin-only tool, and the author of that tool built it in a way that only allows it to be installed in bin(7) and not sbin(7), then don't package the tool. The "alter the tool so it fits with our doctrines" approach hasn't worked.

Again, this isn't Ruby saying "Jeb's network configuration script must go in bin(7) even though he wants it to go in sbin(7)". This is "every Ruby developer writes tools that go in some variant of bin(7)", and Debian not liking that.

Which, fine. Don't like it. Just don't package them.

Don't package them isn't a solution. It's sticking your head in the sand.

Again and again in the Ruby world I see the "it works for us web developers on the x number of hosts we run". The people who use Ruby for stand-alone applications across multiple hosts are largely ignored.

I'd love to see more Ruby out there - ignoring the needs of people other than developers guarantees that'll never happen. Big shops and sys admins who run non-web applications (and even those who run Ruby/Rails web applications and find the RubyGems/Passenger/Rails/Ruby/etc/etc intra/inter version interoperability failures baffling) will look at it as a manual, difficult to package solution and find other tools written in other languages.

That'll be a real shame.

You'd like the Ruby world to be different from what it is, and more like the Debian world. So you broke Ruby. Yes, I get it.

isn't the definition

  /bin system binaries for all users
  /sbin system binaries for root
  /usr/bin distro binaries for all users
  /usr/sbin distro binaries for root
  /usr/local/bin binaries managed by repository, but not by distro for all users
  /usr/local/sbin binaries managed by repository, but not by distro for all root
  /opt/bin/ user compiled and installed binaries for all users
  /opt/sbin/ root compiled and installed binaries for root purposes

more or less? I would expect GEMs to follow behaviour?

Gratuitous differences between Debian and the upstream installation layout are REALLY ANNOYING. It breaks all sorts of online documentation and means Debian users have to deal with unnecessary compatibility bugs.

Is there any reason why you care so much about bin-vs-sbin that would make it such a dealbreaker, other than FHS ideology? Most people I know just care whether the command works, i.e. whether it's in $PATH.

We care because our customers - big, enterprise shops with thousands of hosts they manage with packages - care.

They care that a specific random Ruby utility was by design installed in bin(7) and thus require that Debian specifically modifies the package so that it goes in sbin(7)? I call shenanigans.

You're missing my point - it's a RubyGems issue not a Debian one. Standards matter.

Standards matter, but differ between platforms and even distributions.

Ruby is not—and should not be—beholden to any single distro's particular oddities. Adaptable, yes; broken on other platforms because of, no.

I think the idea is that on every OS you talk the talk. Windows uses backslashes instead of slashes. etc. You meld application to OS, not the other way around.

GEMs on Debian should follow Debian ideology, much like on windows they follow windows way.

I repeat: "…the RubyGems developers have never been unwilling to take patches that make them better citizens."

Code talks. Provide a patch and I'm sure they'll take it, because it's a good step forward. If you do make such a patch, you'll need to consider what should happen if the user is running "gem install" without appropriate privileges or if the user is running on a system where there's no bin/ or sbin/ differentiation (e.g., Windows).