From: Rick DeNatale Date: 2010-09-12T23:25:42+09:00 Subject: [ruby-core:32336] Re: Not using system Ruby on DEbian (was: Re: Re: Can we convert the standard library to gems?) On Sat, Sep 11, 2010 at 10:37 AM, James Tucker wrote: > > On 11 Sep 2010, at 06:52, Markus Fischer wrote: >> I don't want to have poor Debian package Ruby support (or worse: none at >> all) and actually I'd prefer them, it there weren't "those" troubles. >> Now If you ask me which ones: I can't exactly tell them anymore, it was >> some time ago I discovered "rvm" and didn't looked back since ... > > The same is true for a lot of people. One of the larger issues was the fact that a very very unwise decision was made during the switch to gemcutter, that we should drop support for old versions of RubyGems. I don't think I can ever forgive this, it was in my opinion very irresponsible, and if there was a good reason that core could have for maintaining control of bundled RubyGems and gems this would be it. I've expressed this opinion in plenty of places including at the time, as did others, we were ignored. I don't think we should be accepting of this malpractice, or continued retaliation practices in core, otherwise these issues will never be solved. That may be true, but the issues with gems and Debian go back farther than that. When I first started using Ruby on Ubuntu (which of course uses the Debian packaged versions of Ruby etc.) I discovered that some of the debian package maintainers treated certain gems in a rather cavalier manner. For example, at one time (I'm not sure if this is still the case) the executable in the rails gem as packaged for debian, had the ruby executable replaced by a bash script. At the time I asked about this and was advised by more experienced Rubyists to use versions of Ruby and Rubygems installed from source. I've seen the recent emails from the debian maintainers on ruby gems, and there seems to be a central issue about ruby gems, overwriting the commands installed by a gem. While I can see the point, I also have to note that those commands are really just boilerplate generated by rubygems and don't really change with a new version of the gem. For example, here's the ruby script for the rake executable as generated by Rubygems: #!/Users/rick/.rvm/rubies/ruby-1.8.7-p173/bin/ruby # # This file was generated by RubyGems. # # The application 'rake' is installed as part of a gem, and # this file is here to facilitate running it. # require 'rubygems' version = ">= 0" if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then version = $1 ARGV.shift end gem 'rake', version load Gem.bin_path('rake', 'rake', version) ----- Note that the only thing customized in this boilerplate is the name of the gem and executable. So for standard rubygems, it really doesn't matter if it gets replace with the same code. Now of course if a package blows this away with a bash script, then ..... Which is why I've long taken the easy way out as a rubyist on my debian based systems and installed ruby myself either from source or rvm to a part of the FHS tree reserved for local stuff, and kept the debian packages from messing with me. For the most part I too love Debian/Ubuntu, but the maintainers just don't seem to get the rubygems approach to packaging, and as a serious ruby developer, I need the flexibility which standard ruby/rubygems provide and which the packaged versions remove. But that's just my opinion. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale