Re: rails: New upstream release 2.3.5
On 22/02/10 at 01:55 -0600, Adam Majer wrote:
> Ruby problems in Debian - no gems support
> -----------------------------------------
>
> Problems that rails exposes in Debian is lack of concurrent version
> installs. For example, with a split up rails it is impossible to have
> rails 2.x and rails 3.x co-existing. The solution to this problem is
> to allow versioned install, aka gems.
>
> As most of the ruby team knows, most other distributions package
> gems. These gems are then installed in some read-only directory. As an
> example, it could be /usr/lib/rubygems/ or whatever. Packaging gems
> allows has lots of benefits.
>
> 1. It is possible to install multiple versions of a given library at
> the same time. This is crucial if we ever want multiple versions of
> rails installable at same time. update-alternatives is only good to
> manage /usr/bin/rails, not libactiverecord 2.3.5 / 3.0.0 :)
>
> 2. It is distribution transparent - 3rd party software designed to
> work with a specific gem works automatically with the pre-packaged
> Debian gem.
>
> 3. Security fixes for gems are available to 3rd party applications as
> well as to Debian packages.
>
> 4. We *really* need something like sonames. Gems provides that. Other
> scriptable languages (perl, python, etc.) have BIG problems due to
> not having soname-like support.
>
> 5. Less work to get gems working in Debian.
>
>
> Therefore the solution is to package gems and install gems. If gems
> are not the solution, what is?
>
>
> Another problem in ruby is inability to have one package install
> work with all versions of ruby. There is really no need for
> libactiverecord-ruby1.8 and libactiverecord-ruby1.9. Only
> libactiverecord-ruby would suffice. A simple fix for this would be
> addition of /usr/lib/ruby/common where only ruby native packages can
> be installed. Is this something that is possible?
>
> Summary TODO
> ------------
> [...]
> 4. Add support for packaged gems in Debian please :)
I'm a bit surprised/annoyed by your mail. You seem to blame us (other
people involved in Ruby packaging in Debian) for the failure of the
rails package in Debian, resulting in most people simply installing
rails with rubygems.
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.
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.
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.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: