Re: rails: New upstream release 2.3.5

[Adam Majer <adamm@zombino.com>]

On Tue, Feb 23, 2010 at 02:43:14PM +0100, Lucas Nussbaum wrote:
> > 4. Add support for packaged gems in Debian please :)

1st, I do not blame anyone for anything. I simply would like to point
out areas where Debian is lagging behind other distributions. (using
word 'lagging' without intended offence :)


> While Rubygems solve some problems for some Ruby developers, as a way to
> distribute the latest version of some packages, I don't think it
> qualifies as the perfect way to install any ruby library on any system.
> See http://pkg-ruby-extras.alioth.debian.org/rubygems.html for a text
> we wrote some time ago, and still reflect our position accurately.
> 
> You identify the main problem with Ruby packaging in Debian as being
> the inability to co-install several versions of applications like rails,
> because the different versions depend on different versions of some
> libraries, which are incompatible with each other.
> You blame our packaging system for that, and propose to package
> libraries as rubygems.
> 
> I disagree. I think that the fundamental problem is a lack of education
> of developers in the ruby community, wrt API stability, for example.


This may be correct, but if you look at C/C++ ABI and API, they are not
stable either. Yet, it is possible to install multiple versions of a
given library. C/C++ linker address this problem. In Ruby, that linker
is currently gems at runtime.

How do you propose we support multiple versions, like C/C++ does?


> Packaging libraries as rubygems is not a valid solution, as we would end
> up packaging several versions of the same library for different
> applications, creating a hell for stable releases support, for example.

This is correct, but adding ruby gems support does not require us to
package all their versions. To me the most important advantages of
being able to package gems are,

  1. ability to interoperate with 3rd party gem software, and
  2. allows for versioned dependencies, similar to sonames in C/C++

Now, the interop with 3rd party gem software is kind of important for
users. Consider,

  1. install some debian packages, let's call them active_record
  2. you write some app that depends on active_record and some 3rd
  party gem
  3. 3rd party gem depends on active_record

Now you have a scenario where the 3rd party software may bail because
it will not find active_record. Yes, it is partly the fault of that
3rd party gem. The user ends up either installing the gem manually
into their application and maintaining it themselves, or just moves to
gems all together and uses latest versions.

On the other hand, people writing rubygems stopped doing things like,

  require 'foo1'
  require 'foo2'
  require 'foo3'

for version 1.x, 2.x and 3.x. They do,

  gem 'foo', '~> 1.0'
  require 'foo'

  gem 'foo', '~> 2.0'
  require 'foo'

  gem 'foo', '~> 3.0'
  require 'foo'

As ruby software becomes more mature (ie. ages), there will be times
when the above software may work with 'foo' 2.x branch only for quite some
time after 3.x is released. In Debian, this means we will not be able
to support transitions of user software as we will have iehter foo 2.x
or foo 3.x installed.


Finally, rubygems has become a defacto standard of distributing ruby
software. For many developers, the .tar.gz is going away completely in
ruby. I think if 3rd party software wants to pull in libfoo gem, it
should first attempt to use the Debian package instead of a 3rd party
gem.


> If the Ruby community can't fix its own mess, maybe we should consider
> reducing the number of Ruby things that we package. If we can't package
> Rails in a satisfactory way, let's just drop the package. Maybe, then,
> more people will complain about not having a rails package in Debian,
> and we will be able to explain our POV. It still better than having
> people complain about the state of the rubygems package.
> 
> Note that there's also a large amount of mess around the interpreter
> itself: we currently have two development branches (1.8.x and 1.9.x).
> New changes are regularly introduced in 1.8, breaking things, and
> there's no real transition plan between 1.8 and 1.9 AFAIK.

Yes, ruby is a pain this way. I've seen posts (outside Debian) where
apps need at least 1.8.3 but not 1.8.4 but 1.8.5+ works again :) And
how about the 1.9.0 vs. 1.9.1! :)


Cheers,
Adam

PS. No blame or faults. But if we try to keep with the perfect
scenario, it will become more difficult to package ruby
applications. And we will be unable to provide transitions (without
changing library names, which is the rougher end of the stick).


-- 
Adam Majer
adamm@zombino.com