4 ms·

Gem to debian package compability is already terrible. This will make it worse.

tptacek 15y ago
That's because Debian deliberately broke gems. I hardly think the Ruby team should compromise anything to better suit Debian. Debian Rubyists just do a little dance on every install to bring up a fresh Rubygems instance.
- grandalf 15y ago
  In theory, it should be reasonable for a stable linux distro release to lock in stable gem versions that have been tested at the same level as the distro. It's just the case that for Ruby the library ecosystem is being developed at a fast enough pace that few want to settle for gem versions that are 6-18 months old. If the debian ecosystem was actually functioning as designed, someone would create a trusted apt repo with well tested updates that would perhaps be 3 months behind bleeding edge. This would likely be adequate for most ruby projects. It's my impression that the python community is better supported in the debian world. Suggestion: the gem utility should be able to generate deb and rpm packages with proper version numbers, and the utility should also have a setting to "pull from distro repository" to allow things like bundler to be compatible with apt... this would allow/entail letting multiple gem versions live side by side, which would likely seem like a distro-smell to many sysadmins (though it isn't one).
  - tptacek 15y ago
    In my experience the Debian problem goes way beyond not having the most recent gems; they broke Rubygems, so that things like Bundler don't work. No matter what they thought was reasonable, they should have just left gems alone.
    - grandalf 15y ago
      How did they break it? If you don't install ruby from apt, you won't get the debian version of ruby or rubygems, and nothing is broken. Is it reasonable to expect the apt version of ruby + rubygems to play nicely with an arbitrary compiled version that is installed in PATH? It would be nice, but few packages work this way.
      - tptacek 15y ago
        It's reasonable to expect that apt's Ruby/Rubygems works with Bundler in the same sense as it's reasonable to expect that apt's Apache will set the right MIME type for a ".html" file, and not set it "application/binary" by default because some configuration file some Debian person thinks should exist isn't there. Put more simply: if they can't package a rubygems that actually works with the rubygems ecosystem, they should not package rubygems at all.
        grandalf 15y ago
        I think that's a reasonable point.
      - awj 15y ago
        > How did they break it? After their changes, the tool does not function as it was originally intended. Certain sections of the official rubygems documentation give instructions that do not work with the Debian version of rubygems. How is that not broken? In what way did they not break it? I understand and admire Debian's commitment to cleanly built, working software. Within that context I also understand that rubygems is a big, scary unknown. That said, if the only way to solve the problem is to hack up rubygems until it no longer works as intended, the only real answer is to not ship rubygems within Debian. It just flat out has to be left in "here be dragons" land. As things are right now people just get pissed off that Ruby isn't working correctly under Debian, then they have to go play with dragons anyways.
vidarh 15y ago
Does anyone actually use the Debian-packaged gem's for anything at all? About the first thing I do on any new Debian box is to make sure I run a non-Debian rubygems as the Debian one is hopelessly broken, and install any gems I need via bundler. That takes care of that problem.
- technomancy 15y ago
  The $PATH problem has actually been fixed in Debian unstable; they caved on FHS-compliance and let Rubygems place things in the right bin/ dir. Not sure if other issues persist, but finally some progress has been made.
- yxhuvud 15y ago
  Yes. People that don't know better, and people that are only installing dist packaged stuff. I know a lot of people in the second group, though most of those doesn't use Ruby.
knotty66 15y ago
Most Rubyists install Ruby & RubyGems through RVM nowadays anyway so it will make no difference.
- aledalgrande 15y ago
  Yes, why mess with a system VM any more. RVM is cool for servers too, not only dev.
getsat 15y ago
The amount of control the Debian team wants to retain and the speed at which the Ruby/RubyGems community moves are incompatible. Trying to use Ruby from apt is some kind of sick, masochistic joke.
deleted 15y ago
[deleted]
inopinatus 15y ago
It is possible for <language native package> and <OS native package> systems to play nicely together. In FreeBSD, for example, there's a system called BSDPAN which allows installed Perl CPAN modules to magically appear (and be managed as) OS packages. Unfortunately, APT/dpkg don't have a concept of a "virtual provider" of packages.

That's because Debian deliberately broke gems. I hardly think the Ruby team should compromise anything to better suit Debian. Debian Rubyists just do a little dance on every install to bring up a fresh Rubygems instance.

grandalf 15y ago
In theory, it should be reasonable for a stable linux distro release to lock in stable gem versions that have been tested at the same level as the distro. It's just the case that for Ruby the library ecosystem is being developed at a fast enough pace that few want to settle for gem versions that are 6-18 months old. If the debian ecosystem was actually functioning as designed, someone would create a trusted apt repo with well tested updates that would perhaps be 3 months behind bleeding edge. This would likely be adequate for most ruby projects. It's my impression that the python community is better supported in the debian world. Suggestion: the gem utility should be able to generate deb and rpm packages with proper version numbers, and the utility should also have a setting to "pull from distro repository" to allow things like bundler to be compatible with apt... this would allow/entail letting multiple gem versions live side by side, which would likely seem like a distro-smell to many sysadmins (though it isn't one).
- tptacek 15y ago
  In my experience the Debian problem goes way beyond not having the most recent gems; they broke Rubygems, so that things like Bundler don't work. No matter what they thought was reasonable, they should have just left gems alone.
  - grandalf 15y ago
    How did they break it? If you don't install ruby from apt, you won't get the debian version of ruby or rubygems, and nothing is broken. Is it reasonable to expect the apt version of ruby + rubygems to play nicely with an arbitrary compiled version that is installed in PATH? It would be nice, but few packages work this way.
    - tptacek 15y ago
      It's reasonable to expect that apt's Ruby/Rubygems works with Bundler in the same sense as it's reasonable to expect that apt's Apache will set the right MIME type for a ".html" file, and not set it "application/binary" by default because some configuration file some Debian person thinks should exist isn't there. Put more simply: if they can't package a rubygems that actually works with the rubygems ecosystem, they should not package rubygems at all.
      - grandalf 15y ago
        I think that's a reasonable point.
    - awj 15y ago
      > How did they break it? After their changes, the tool does not function as it was originally intended. Certain sections of the official rubygems documentation give instructions that do not work with the Debian version of rubygems. How is that not broken? In what way did they not break it? I understand and admire Debian's commitment to cleanly built, working software. Within that context I also understand that rubygems is a big, scary unknown. That said, if the only way to solve the problem is to hack up rubygems until it no longer works as intended, the only real answer is to not ship rubygems within Debian. It just flat out has to be left in "here be dragons" land. As things are right now people just get pissed off that Ruby isn't working correctly under Debian, then they have to go play with dragons anyways.

vidarh 15y ago

Does anyone actually use the Debian-packaged gem's for anything at all? About the first thing I do on any new Debian box is to make sure I run a non-Debian rubygems as the Debian one is hopelessly broken, and install any gems I need via bundler. That takes care of that problem.

technomancy 15y ago
The $PATH problem has actually been fixed in Debian unstable; they caved on FHS-compliance and let Rubygems place things in the right bin/ dir. Not sure if other issues persist, but finally some progress has been made.
yxhuvud 15y ago
Yes. People that don't know better, and people that are only installing dist packaged stuff. I know a lot of people in the second group, though most of those doesn't use Ruby.

knotty66 15y ago

Most Rubyists install Ruby & RubyGems through RVM nowadays anyway so it will make no difference.

aledalgrande 15y ago
Yes, why mess with a system VM any more. RVM is cool for servers too, not only dev.

getsat 15y ago

The amount of control the Debian team wants to retain and the speed at which the Ruby/RubyGems community moves are incompatible. Trying to use Ruby from apt is some kind of sick, masochistic joke.

deleted 15y ago

[deleted]

inopinatus 15y ago

It is possible for <language native package> and <OS native package> systems to play nicely together. In FreeBSD, for example, there's a system called BSDPAN which allows installed Perl CPAN modules to magically appear (and be managed as) OS packages. Unfortunately, APT/dpkg don't have a concept of a "virtual provider" of packages.