3 ms·

> 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 para

> 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.
rimantas 16y ago
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. Here you ara basically saying that you want Debian to be easy for those who do packages, not for those who are going to actually use them. That explains a lot.
- __david__ 16y ago
  No, I'm not saying that at all! I am not a Debian developer. I have made packages so I understand what goes into them, but that statement was driven by me as a Debian user--when things are consistent it makes life so much easier.

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.

rimantas 16y ago

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. Here you ara basically saying that you want Debian to be easy for those who do packages, not for those who are going to actually use them. That explains a lot.

__david__ 16y ago
No, I'm not saying that at all! I am not a Debian developer. I have made packages so I understand what goes into them, but that statement was driven by me as a Debian user--when things are consistent it makes life so much easier.