5 ms·

The approach that rubygems works terrifically, and is depended upon by the Ruby community — you can trivially install as many versions of the same gem as you wa

by blasdel 16y ago

The approach that rubygems works terrifically, and is depended upon by the Ruby community — you can trivially install as many versions of the same gem as you want to satisfy the dependency requirements of other gems and apps. Library authors can fix mistakes and take advantage of new functionality in other libraries without worry. Everything about Debian's approach is in rabid opposition to this. They want to scatter the files all over their precious FHS. They want to install as few versions of libraries as possible, and where multiple versions must be installed in the best case the names sre mangled because apt does not have a 'slots' mechanism (average case they use the mediocre 'alternatives' system, worst case there are multiple independent depgraphs!). On top of all of that there's their release cycle where they freeze all the packages at a particular version number for several years for normal users (and regular 3-6 month periods on the 'bleeding edge'), after which they start mutilating random patches from upstream as 'support' instead of just shipping the new versions. You're right that there's no way to reconcile this fundamental schism. You're wrong about which community is breaking everything.

__david__ 16y ago
> Everything about Debian's approach is in rabid opposition to this. This is not necessarily true. There are many Debian packages that can be installed in parallel. I still have gcc-2.95 installed and that hasn't been available in the Debian archive for years. It is named properly and doesn't conflict with any of the newer gccs. So it is possible to make parallel installs. > They want to scatter the files all over their precious FHS. This is true. And as a Debian user, I support them fully. I don't want to learn some stupid Ruby package directory convention. I already know if I install a Debian package that the configuration files go in /etc/packagename and the docs are in /usr/share/doc/packagename. Every package is like that and consistency is a good thing. I think the Debian Perl maintainers have gotten this right. They have a program "dh-make-perl" that will download a CPAN package and make it into a Debian package. This really gets you the best of both worlds. Hopefully something like that will get written for Python and Ruby (they haven't had their CPAN clones out for as long as CPAN, so give it time). > On top of all of that there's their release cycle where they freeze all the packages at a particular version number for several years for normal users. That's not just a Debian thing. %$#@! RHEL still ships a 2.6.18 kernel in their latest release! There is a certain class of people who are very, very conservative with their software upgrades. Debian Stable and RHEL appeal to those types. If you aren't one of those types, don't run them--instead run Debian Unstable or Fedora or Ubuntu. Those stay on the bleeding edge most of the time.
- blasdel 16y ago
  > I still have gcc-2.95 installed and that hasn't been available in the Debian archive for years. It is named properly and doesn't conflict with any of the newer gccs. So it is possible to make parallel installs. It is NOT named properly — they mangle the name of the package to be 'gcc-2.95' to make this work. They only do this when they really can't get away with it otherwise because other base packages have hard low-level dependencies. > RHEL still ships a 2.6.18 kernel in their latest release! The ancient base kernel is mostly just so that commercial drivers never get ABI breakage. Most other things at least have newer versions available at more recent patchlevels, community repositories are maintained, and shit can be installed directly from upstream without the sanctimony. Really RHEL just leads you directly towards the correct conclusion (that Debian tries to talk you out of) — treat the distro system as a general starting point, and install everything directly relevant to your usage from upstream. Use the distro packages for native dependencies, not applications you really care about.
  - __david__ 16y ago
    > It is NOT named properly — they mangle the name of the package to be 'gcc-2.95' to make this work. So what? If it installs in parallel and still works after umpteen years, how is it not "proper"? It seems like you want to have it both ways--on the one hand you bash Debian for hacking versions into the package names for practical reasons, then praise the practicality of RHEL because you can install crap from Joe Shmoe's public repository (btw, would you really do that on your company's server??). All the while ignoring the fact that you can use "alien" to install rpms on a Debian machine (it's not perfect, but I've had good luck and have been able to experience the wonderful world of random junk in /opt) and that there are a bunch of Debian repos out there to get stuff that isn't in the official repository...
    - halostatue 16y ago
      It's not "so what," and what RubyGems does really matters for version management within an application. If I have one application that depends on version 1.3 of a library, it can do: gem 'library', '~>1.3' # 1.3 and higher, but not less than 1.4 require 'library/file' The next application that requires 1.5 or later can do: gem 'library', '~>1.5' # 1.5 and higher, but not less than 1.6 require 'library/file' There's two things here: Debian typically won't include two versions like that; they might include library1 and library2, but not 1.3 and 1.5. Second, I only have to have the 'gem' method in one location; everywhere else I can just do "require 'library/file'". I don't have to go through my source to change "require 'library-1.3/file'" to "require 'library-1.5/file'" when I want to upgrade. The Debian approach works...fairly well for compiled applications, but it's utter crap for dynamic languages like Ruby. The RubyGems approach is superior for Ruby, and it fills a very important need for Ruby: it works on platforms other than Debian. Debian packagers assume that they're the only packager in the world that matters. They're not, and other vendors have done infinitely better jobs of handling packaging Ruby than Debian, mostly because other vendors actually write patches for the upstream providers instead of bitching that the system isn't compatible. (See what Apple did for RubyGems. It still required work on the RubyGems side, but it was at least usable and didn't break the fundamental behaviour of RubyGems.) If Debian packagers want more respect from upstream developers, they need to stop treating us like we're the ones doing something wrong. If we've developed something, it's because there's something missing.
regularfry 16y ago
> you can trivially install as many versions of the same gem as you want to satisfy the dependency requirements of other gems and apps. You say that like it's a good thing. The ability to do that is a large part of why it's broken. If you're a developer, yes, it's extremely convenient, and it means you never have to worry about API stability, back-ported security fixes, or even semantic versioning. You just bump the version number and push out a new release. It's a great developer tool that happens to also work for deployment if you're deploying in a language monoculture. If you're a general sysadmin, or targeting a system where rubygems isn't suitable (embedding ruby, for example), it's a bloody nightmare. > They want to scatter the files all over their precious FHS The "precious FHS" is part of what keeps sysadmins sane, and splitting packages isn't a problem unless filename conflicts happen. I know that rspec and cucumber used to have a problem here, I don't know if it's been fixed. > They want to install as few versions of libraries as possible Yes, and that is the correct approach if everything is supposed to be under control of the OS. > after which they start mutilating random patches from upstream as 'support' instead of just shipping the new versions. Again, this is the right thing to do, if upstream won't provide fixes, or keep to any kind of API or dependency stability. In the Ruby community, new versions tends to mean new features, which inevitably means new bugs. > You're right that there's no way to reconcile this fundamental schism. I didn't say that. I believe it's firmly reconcilable, with a mechanism not unlike backports. However, it does need gem authors to lay off some particularly inconvenient practices for it to be manageable. Just adhering to the RPG would be a good start. > You're wrong about which community is breaking everything. Rubygems is the latecomer here - standards like the FHS have been evolved over a generation before this little head-to-head happened. Besides, I don't think the "community" is breaking things. I think the "community" is behaving in a way promoted by a broken tool.

by blasdel 16y ago

__david__ 16y ago

> Everything about Debian's approach is in rabid opposition to this. This is not necessarily true. There are many Debian packages that can be installed in parallel. I still have gcc-2.95 installed and that hasn't been available in the Debian archive for years. It is named properly and doesn't conflict with any of the newer gccs. So it is possible to make parallel installs. > They want to scatter the files all over their precious FHS. This is true. And as a Debian user, I support them fully. I don't want to learn some stupid Ruby package directory convention. I already know if I install a Debian package that the configuration files go in /etc/packagename and the docs are in /usr/share/doc/packagename. Every package is like that and consistency is a good thing. I think the Debian Perl maintainers have gotten this right. They have a program "dh-make-perl" that will download a CPAN package and make it into a Debian package. This really gets you the best of both worlds. Hopefully something like that will get written for Python and Ruby (they haven't had their CPAN clones out for as long as CPAN, so give it time). > On top of all of that there's their release cycle where they freeze all the packages at a particular version number for several years for normal users. That's not just a Debian thing. %$#@! RHEL still ships a 2.6.18 kernel in their latest release! There is a certain class of people who are very, very conservative with their software upgrades. Debian Stable and RHEL appeal to those types. If you aren't one of those types, don't run them--instead run Debian Unstable or Fedora or Ubuntu. Those stay on the bleeding edge most of the time.

blasdel 16y ago
> I still have gcc-2.95 installed and that hasn't been available in the Debian archive for years. It is named properly and doesn't conflict with any of the newer gccs. So it is possible to make parallel installs. It is NOT named properly — they mangle the name of the package to be 'gcc-2.95' to make this work. They only do this when they really can't get away with it otherwise because other base packages have hard low-level dependencies. > RHEL still ships a 2.6.18 kernel in their latest release! The ancient base kernel is mostly just so that commercial drivers never get ABI breakage. Most other things at least have newer versions available at more recent patchlevels, community repositories are maintained, and shit can be installed directly from upstream without the sanctimony. Really RHEL just leads you directly towards the correct conclusion (that Debian tries to talk you out of) — treat the distro system as a general starting point, and install everything directly relevant to your usage from upstream. Use the distro packages for native dependencies, not applications you really care about.
- __david__ 16y ago
  > It is NOT named properly — they mangle the name of the package to be 'gcc-2.95' to make this work. So what? If it installs in parallel and still works after umpteen years, how is it not "proper"? It seems like you want to have it both ways--on the one hand you bash Debian for hacking versions into the package names for practical reasons, then praise the practicality of RHEL because you can install crap from Joe Shmoe's public repository (btw, would you really do that on your company's server??). All the while ignoring the fact that you can use "alien" to install rpms on a Debian machine (it's not perfect, but I've had good luck and have been able to experience the wonderful world of random junk in /opt) and that there are a bunch of Debian repos out there to get stuff that isn't in the official repository...
  - halostatue 16y ago
    It's not "so what," and what RubyGems does really matters for version management within an application. If I have one application that depends on version 1.3 of a library, it can do: gem 'library', '~>1.3' # 1.3 and higher, but not less than 1.4 require 'library/file' The next application that requires 1.5 or later can do: gem 'library', '~>1.5' # 1.5 and higher, but not less than 1.6 require 'library/file' There's two things here: Debian typically won't include two versions like that; they might include library1 and library2, but not 1.3 and 1.5. Second, I only have to have the 'gem' method in one location; everywhere else I can just do "require 'library/file'". I don't have to go through my source to change "require 'library-1.3/file'" to "require 'library-1.5/file'" when I want to upgrade. The Debian approach works...fairly well for compiled applications, but it's utter crap for dynamic languages like Ruby. The RubyGems approach is superior for Ruby, and it fills a very important need for Ruby: it works on platforms other than Debian. Debian packagers assume that they're the only packager in the world that matters. They're not, and other vendors have done infinitely better jobs of handling packaging Ruby than Debian, mostly because other vendors actually write patches for the upstream providers instead of bitching that the system isn't compatible. (See what Apple did for RubyGems. It still required work on the RubyGems side, but it was at least usable and didn't break the fundamental behaviour of RubyGems.) If Debian packagers want more respect from upstream developers, they need to stop treating us like we're the ones doing something wrong. If we've developed something, it's because there's something missing.

regularfry 16y ago

> you can trivially install as many versions of the same gem as you want to satisfy the dependency requirements of other gems and apps. You say that like it's a good thing. The ability to do that is a large part of why it's broken. If you're a developer, yes, it's extremely convenient, and it means you never have to worry about API stability, back-ported security fixes, or even semantic versioning. You just bump the version number and push out a new release. It's a great developer tool that happens to also work for deployment if you're deploying in a language monoculture. If you're a general sysadmin, or targeting a system where rubygems isn't suitable (embedding ruby, for example), it's a bloody nightmare. > They want to scatter the files all over their precious FHS The "precious FHS" is part of what keeps sysadmins sane, and splitting packages isn't a problem unless filename conflicts happen. I know that rspec and cucumber used to have a problem here, I don't know if it's been fixed. > They want to install as few versions of libraries as possible Yes, and that is the correct approach if everything is supposed to be under control of the OS. > after which they start mutilating random patches from upstream as 'support' instead of just shipping the new versions. Again, this is the right thing to do, if upstream won't provide fixes, or keep to any kind of API or dependency stability. In the Ruby community, new versions tends to mean new features, which inevitably means new bugs. > You're right that there's no way to reconcile this fundamental schism. I didn't say that. I believe it's firmly reconcilable, with a mechanism not unlike backports. However, it does need gem authors to lay off some particularly inconvenient practices for it to be manageable. Just adhering to the RPG would be a good start. > You're wrong about which community is breaking everything. Rubygems is the latecomer here - standards like the FHS have been evolved over a generation before this little head-to-head happened. Besides, I don't think the "community" is breaking things. I think the "community" is behaving in a way promoted by a broken tool.