[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

rails: New upstream release 2.3.5

This message is directed to everyone that has some interest in having
rails 2.3.5+ in Squeeze.

On Sat, Feb 20, 2010 at 06:39:53AM -0500, Richard Hurt wrote:
> On 2/19/10 8:33 AM| Feb 19, 2010, Malcolm Locke wrote:
> >
> >I think probably most users have abandoned this package and are now
> >using gem install to get Rails, however it would still be nice to get
> >this up to date.
> Consider this another vote for Rails 2.3.x.

State of Rails

Rails package needs to be split up. Long in the past, rails used to be a
very integrated - this is definitely changing. With the upcoming 3.x
release different components that constitute rails will become even more
useful as independent elements.

Split up of rails is overdue, and that is mostly my fault. By the time
I've decided splitting up rails was a good idea, Roberto C. Sanchez
has already uploaded libactiverecord-ruby - I took too much time (and
I was resistant to splitting up rails because I wanted to avoid the
mess of zope packages). As a result, the following packages will need
to be removed from Debian first before split up rails can replace them,


Package split also exposes problems in the Debian's ruby
infrastructure, but I'll get to that later.

Current split up rails 2.3.5 package is available at,


It requires the following two dependencies that cannot be satisfied in Sid,

   libi18n-ruby1.8 (>> 0.1.3)
   libmemcache-client-ruby1.8 (>> 1.7.4)

It is possible to install older versions from Sid and force-depends to
install the new packages. The resulting rails package functions, but I
do not know to what extent.

Co-maintainer(s) of rails

rails sources are available at the following link for quite some time


See v2.3-stable branch for current development area. If you are a DD,
you may push your changes to this branch. I would like to maintain the
packages split for 2.3.5 as is. The TODO list here would be,

1. Add -ruby and -ruby1.9 packages for the split up lib* packages.
   rails probably should remain as rails with dependency on
   rails-ruby1.8 | rails-ruby1.9. Lots of copy/pasting here.

2. Get rid of lintian warnings - this is not by changing upstream
sources please :) The warning regarding script-not-executable are

3. Fix compilation of guides. This fix would then needs to be
propagated upstream. Guides are in railties/guides. They don't build
and it would be nice to have them included in rails-doc.

4. Look at the rails package. Currently, railties is not packaged the
Debian way. I simply dumped railties into
/usr/share/rails/railties due to number of reasons, mostly upstream
path dependencies (again, gems).. Ideas on how to make this 'prettier'
are very welcome.

If you would like to become a co-maintainer of rails, please fix
something in the package, push fix to repository, and email me.

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

1. Remove (Roberto C. Sanchez <roberto@connexer.com> please :),

2. Update,
   libi18n-ruby1.8 (>> 0.1.3)
   libmemcache-client-ruby1.8 (>> 1.7.4)

3. Upload of split up rails 2.3.5 becomes possible

4. Add support for packaged gems in Debian please :)

- Adam

Adam Majer

Attachment: signature.asc
Description: Digital signature

Reply to: