4 ms·

Wow. I'm not going to claim that rubygems is the best package management system, or that it's better than debian's packaging system. But, some of your frustra

by Locke 18y ago

Wow. I'm not going to claim that rubygems is the best package management system, or that it's better than debian's packaging system. But, some of your frustration comes from the fact that you know apt very well and you don't seem to know rubygems very well. For example, you can setup your own local gem server. You can load it with only the gems you want to install on your fleet of machines and use 'gem install --source your-local-server fastthread', for example. You might even get around your "pick the right gem" problem by installing only the fastthread gem you need on your local server. But, I think the real problem you have with rubygems is that you don't want to learn another package management system. I really don't think the rubygems devs can do anything to remedy that problem.

e1ven 18y ago
Great point, Locke, Thanks for replying. I'll certainly admit that I don't know the gems packaging system as well as I know dpkg and aptitude, but I think that that criticism misses the larger issue. You're certainly right that the gems system could be made to do everything that the Debian/Ubuntu system does, particularly if given time to mature. But as I pointed out in my post, this wouldn't fix the problem. Apache, for example, has hundreds of modules, each of which have complex dependencies.. They're released on their own schedule, and they're released across lots of platforms. Firefox has it's own set of extensions, and updates- You see the same thing with CPAN, and Python modules. But the more disparate systems you add, the more sets of configurations you need, the more repositories you need, and the more ways to update everything you need. So for our servers, I could set up a Gems repo, an Apache repo, a System Software Repo, a Cpan repo. I could have separate upgrade commands for every software package that comes along. But the complexity is increased with each addition to this system- * If I want to get a list of everything that's installed under this system, I need to run X commands. * During installations, I can't chain everything together, I need to run X set of separate installations. * I need to review X different release chains, to see if there are packages I need to test before deploying to multiple machine * And yes, I need to learn X different systems for installing software, rather than one system for installing system wide. There are a lot of good reasons to have the gems system, and I think it's a great tool for individual systems, but for anything that's going farm-wide, It's substantially easier to have everything go through one tool.
- Locke 18y ago
  I don't know that I particularly disagree with you. The one advantage that a language scoped packaging system has over a system-wide system is developer adoption. Debian, Gentoo, Redhat, FreeBSD, etc all depend on heavily on volunteers to create the packages, manage dependencies, issue security announcements, feed bug reports and patches upstream to developers, etc. I've used Gentoo for a long time and I've watched it struggle in recent years as it loses volunteers. New releases take longer to reach portage, some software never finds its way to portage at all, and I find more and more broken packages. The only Ruby package I install from portage is Ruby itself. The thing is, every Ruby developer uses RubyGems. There are no volunteers because the developers themselves create the packages for each release. I think this is more sustainable, even if I don't think RubyGems is as good as the packaging tools used by the major distributions.
  - e1ven 18y ago
    That's a really great point, and one I hadn't considered. Of course, in a fantasy ideal world, the way things would work is that the Ruby developers would create their own repository for .debs.. This would mean that if I want the latest and greatest files, I can add their repository to my existing package system, and everything integrates. When I did an "apt-get upgrade" it would check the Ruby repository, and upgrade all my ruby packages, too.. Then, when a package had proven itself to be stable enough, it could be copied back into the standard Ubuntu/Debian repositories, so that everyone could have it, even if they didn't add the repositories. Of course, in the real world, that would be far to much work for the Ruby developers, and would require that they customize for one specific OS.. But a man can dream, can't he? ;)
nailer 18y ago
"But, I think the real problem you have with rubygems is that you don't want to learn another package management system. I really don't think the rubygems devs can do anything to remedy that problem." You don't think the RubyGems devs can use the normal packaging system, and hence get rid of these odd requirements? Why not?
- halostatue 18y ago
  Because a lot of us either (a) want what RubyGems offers (multiple version side-by-side installations), (b) work on operating systems that don't have packaging systems and aren't willing to compromise the use of our language just because of <platform> bigotry, or (c) want something newer faster than <platform> can provide it without having to install from source and without breaking our existing apps (see point a again). Unless and until Debian supports the concept of multiple version side-by-side installations which is IMO mandatory, I don't see this particular problem being resolved.
  - nailer 18y ago
    DPkg indeed already supports multiple side by side versions, as does RPM. I'm not sure why you think they don't. I'm also unsure why wanting an app to install its files to the same standard directories that other apps do, and not require separate updating tools, constitutes bigotry. Can you explain?
    - halostatue 18y ago
      1. If by "already supports multiple side-by-side versions" you mean the support for libfoo and libfoo2, this isn't multiple side by side. I mean being able to support foo 2.1 and 2.1.3 simultaneously. RubyGems can do this, and applications that only want 2.1 and nothing later can specify that. My understanding and experience that what RubyGems can do here isn't supported by dpkg or RPM; even if they are, the maintainers of Debian aren't interested in it because it doesn't fit their narrow worldview. 2. Even if what RubyGems does is supported by dpkg et al., this does nothing to help the language or programs written in the language support this without resorting to ugly, stupid, and nonsensical platform-specific hacks. We've already seen people on Ruby doing a few silly things (e.g., RUBY_PLATFORM =~ /win/ matches darwin, cygwin, and win32, but doesn't match mingw -- which is a closer match for win32 than darwin or cygwin ;). Doing "gem 'foo', '=2.1'" allows me to use a specific version (equivalent of -lfoo2 in linking in C++), but if I don't care, I can just require 'foo'. (The "require 'foo'" bit is required in any case; "gem 'foo', '=2.1'" doesn't require anything, but sets the load paths.) 3. The bigotry is in assuming that dpkg or RPM are appropriate for everyone. I would rather have a Ruby-centric system for Ruby rather than two dozen platform-specific systems that I have to know and support. Yes, I'm bigoted toward Ruby and don't care what platform I run Ruby on. I don't want to have to deal with the operating system's package management (or lack thereof, as is the case on systems with wider adoption than Linux). RubyGems isn't perfect or a be-all, end-all packaging system. It doesn't try to be. What it does, however, it does very well and it does right.

by Locke 18y ago

e1ven 18y ago

Great point, Locke, Thanks for replying. I'll certainly admit that I don't know the gems packaging system as well as I know dpkg and aptitude, but I think that that criticism misses the larger issue. You're certainly right that the gems system could be made to do everything that the Debian/Ubuntu system does, particularly if given time to mature. But as I pointed out in my post, this wouldn't fix the problem. Apache, for example, has hundreds of modules, each of which have complex dependencies.. They're released on their own schedule, and they're released across lots of platforms. Firefox has it's own set of extensions, and updates- You see the same thing with CPAN, and Python modules. But the more disparate systems you add, the more sets of configurations you need, the more repositories you need, and the more ways to update everything you need. So for our servers, I could set up a Gems repo, an Apache repo, a System Software Repo, a Cpan repo. I could have separate upgrade commands for every software package that comes along. But the complexity is increased with each addition to this system- * If I want to get a list of everything that's installed under this system, I need to run X commands. * During installations, I can't chain everything together, I need to run X set of separate installations. * I need to review X different release chains, to see if there are packages I need to test before deploying to multiple machine * And yes, I need to learn X different systems for installing software, rather than one system for installing system wide. There are a lot of good reasons to have the gems system, and I think it's a great tool for individual systems, but for anything that's going farm-wide, It's substantially easier to have everything go through one tool.

Locke 18y ago
I don't know that I particularly disagree with you. The one advantage that a language scoped packaging system has over a system-wide system is developer adoption. Debian, Gentoo, Redhat, FreeBSD, etc all depend on heavily on volunteers to create the packages, manage dependencies, issue security announcements, feed bug reports and patches upstream to developers, etc. I've used Gentoo for a long time and I've watched it struggle in recent years as it loses volunteers. New releases take longer to reach portage, some software never finds its way to portage at all, and I find more and more broken packages. The only Ruby package I install from portage is Ruby itself. The thing is, every Ruby developer uses RubyGems. There are no volunteers because the developers themselves create the packages for each release. I think this is more sustainable, even if I don't think RubyGems is as good as the packaging tools used by the major distributions.
- e1ven 18y ago
  That's a really great point, and one I hadn't considered. Of course, in a fantasy ideal world, the way things would work is that the Ruby developers would create their own repository for .debs.. This would mean that if I want the latest and greatest files, I can add their repository to my existing package system, and everything integrates. When I did an "apt-get upgrade" it would check the Ruby repository, and upgrade all my ruby packages, too.. Then, when a package had proven itself to be stable enough, it could be copied back into the standard Ubuntu/Debian repositories, so that everyone could have it, even if they didn't add the repositories. Of course, in the real world, that would be far to much work for the Ruby developers, and would require that they customize for one specific OS.. But a man can dream, can't he? ;)

nailer 18y ago

"But, I think the real problem you have with rubygems is that you don't want to learn another package management system. I really don't think the rubygems devs can do anything to remedy that problem." You don't think the RubyGems devs can use the normal packaging system, and hence get rid of these odd requirements? Why not?

halostatue 18y ago
Because a lot of us either (a) want what RubyGems offers (multiple version side-by-side installations), (b) work on operating systems that don't have packaging systems and aren't willing to compromise the use of our language just because of <platform> bigotry, or (c) want something newer faster than <platform> can provide it without having to install from source and without breaking our existing apps (see point a again). Unless and until Debian supports the concept of multiple version side-by-side installations which is IMO mandatory, I don't see this particular problem being resolved.
- nailer 18y ago
  DPkg indeed already supports multiple side by side versions, as does RPM. I'm not sure why you think they don't. I'm also unsure why wanting an app to install its files to the same standard directories that other apps do, and not require separate updating tools, constitutes bigotry. Can you explain?
  - halostatue 18y ago
    1. If by "already supports multiple side-by-side versions" you mean the support for libfoo and libfoo2, this isn't multiple side by side. I mean being able to support foo 2.1 and 2.1.3 simultaneously. RubyGems can do this, and applications that only want 2.1 and nothing later can specify that. My understanding and experience that what RubyGems can do here isn't supported by dpkg or RPM; even if they are, the maintainers of Debian aren't interested in it because it doesn't fit their narrow worldview. 2. Even if what RubyGems does is supported by dpkg et al., this does nothing to help the language or programs written in the language support this without resorting to ugly, stupid, and nonsensical platform-specific hacks. We've already seen people on Ruby doing a few silly things (e.g., RUBY_PLATFORM =~ /win/ matches darwin, cygwin, and win32, but doesn't match mingw -- which is a closer match for win32 than darwin or cygwin ;). Doing "gem 'foo', '=2.1'" allows me to use a specific version (equivalent of -lfoo2 in linking in C++), but if I don't care, I can just require 'foo'. (The "require 'foo'" bit is required in any case; "gem 'foo', '=2.1'" doesn't require anything, but sets the load paths.) 3. The bigotry is in assuming that dpkg or RPM are appropriate for everyone. I would rather have a Ruby-centric system for Ruby rather than two dozen platform-specific systems that I have to know and support. Yes, I'm bigoted toward Ruby and don't care what platform I run Ruby on. I don't want to have to deal with the operating system's package management (or lack thereof, as is the case on systems with wider adoption than Linux). RubyGems isn't perfect or a be-all, end-all packaging system. It doesn't try to be. What it does, however, it does very well and it does right.