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).