3 ms·

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 s

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.

nailer 18y ago
1. I mean being able to support foo 2.1 and 2.1.3 simultaneously. Like every Linux distro shipped GCC296 and GCC29x for years? It seems the Ruby community (and the Python community to a lesser extent) have a Not Invented Here syndrome. 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 Yes it does. Dpkg and RPM provide a standard mechanism to query if software is installed (foo), including optionally what verion is installed (foo >= 2.1). 3. I think the greater bigotry exists in assuming that Ruby is somehow special, and deserves to write unsigned binaries all over systems although all other software does not. Python, Java, and other languages all make the effort to integrate into their environments rather than forcing a whole new mechanism of querying, fetching, downloading, verifying, and signature checking upon users.

nailer 18y ago

1. I mean being able to support foo 2.1 and 2.1.3 simultaneously. Like every Linux distro shipped GCC296 and GCC29x for years? It seems the Ruby community (and the Python community to a lesser extent) have a Not Invented Here syndrome. 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 Yes it does. Dpkg and RPM provide a standard mechanism to query if software is installed (foo), including optionally what verion is installed (foo >= 2.1). 3. I think the greater bigotry exists in assuming that Ruby is somehow special, and deserves to write unsigned binaries all over systems although all other software does not. Python, Java, and other languages all make the effort to integrate into their environments rather than forcing a whole new mechanism of querying, fetching, downloading, verifying, and signature checking upon users.