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, libactivesupport-ruby libactiverecord-ruby 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, http://people.debian.org/~adamm/rails/ 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 now, http://git.debian.org/?p=collab-maint/rails.git 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 incorrect. 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 :), libactivesupport-ruby libactiverecord-ruby 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 adamm@zombino.com
Attachment:
signature.asc
Description: Digital signature