Hypothetical question: Now that rvm has been created, would anyone still use apt-get to install ruby even if the latest version was supported?
Sure you could argue that yes, ruby should be installed with apt-get and alternative versions should be handled with Debian's alternatives infrastructure...
I think this is an interesting case in which version numbers are more than just version numbers, they are more like sister projects, and they don't fall neatly into the "conservative and stable" or "bleeding edge and risky" camps the way maintainers typically view different versions.
From the perspective of a package maintainer, if we had to include an alternatives list for every dot version of every package, then the distro would explode in complexity.
Ruby and Python just happened to grow so quickly that their growth didn't immediately trigger the appropriate response from distro maintainers, and very quickly the community worked around the problem.
> would anyone still use apt-get to install ruby even if the latest version was supported?
Not everyone is a heavy Ruby user - someone might just want to install a package that depends on Ruby and be sure that things work. Just as they may want to install a package that depends on Java, Ada, Haskell, Erlang, Perl, Python, PHP, Ocaml, Tcl or any of the many other languages present in Debian, and not have to deal with a different package management system for each language on the computer.
> Ruby and Python just happened to grow so quickly that their growth didn't immediately trigger the appropriate response from distro maintainers
It's actually a fairly old problem. Perl and CPAN have many of the same issues. I'm not sure there's a perfect solution.
apt-get or yum for ruby? Hell yes. After wasting countless hours on random versions of crap scattered around some servers' filesystems but not others, now nothing hits production without being in a package that installs and uninstalls cleanly and declares everything it relies on being present. That includes my own code, which we package ourselves.
Hear hear. Nothing strikes fear in my heart like a /usr/local hierarchy filled with a million random versions of random programs. BTW, if you are going to install something into /usr/local, at least use a cheap and easy packager like GNU "stow".
A user can manage his/her own stuff in ~/bin and add it to path if he/she wants.
A sysadmin can put things somewhere like /usr/local/experiment33 and make sweeping changes just by changing the default path, which a user could override for customization.
> Ruby and Python just happened to grow so quickly that their growth didn't immediately trigger the appropriate response from distro maintainers, and very quickly the community worked around the problem.
This is true, but it's more than that. Ruby and Python are both committed to working on a wide variety of platforms, including platforms that don't have native package management systems (Windows, Mac OS X, Solaris, etc.). For Ruby programs and libraries, RubyGems are a more elegant solution than telling people 10 - 20 different ways on how to work with their project, depending on the OS.
Sure you could argue that yes, ruby should be installed with apt-get and alternative versions should be handled with Debian's alternatives infrastructure...
I think this is an interesting case in which version numbers are more than just version numbers, they are more like sister projects, and they don't fall neatly into the "conservative and stable" or "bleeding edge and risky" camps the way maintainers typically view different versions.
From the perspective of a package maintainer, if we had to include an alternatives list for every dot version of every package, then the distro would explode in complexity.
Ruby and Python just happened to grow so quickly that their growth didn't immediately trigger the appropriate response from distro maintainers, and very quickly the community worked around the problem.