[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 <[e-mail]> 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 fa=
ct 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 the=
re was a good reason that core could have for maintaining control of bundle=
d 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 t=
hink we should be accepting of this malpractice, or continued retaliation p=
ractices 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 =3D ">=3D 0"

if ARGV.first =3D~ /^_(.*)_$/ and Gem::Version.correct? $1 then
  version =3D $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.
--=20
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