[DRE-maint] Bug#462027: ITP: libactiverecord-ruby -- library that ties database tables to classes in Ruby

Adam Majer adamm at zombino.com
Thu Jan 24 07:36:47 UTC 2008


Gunnar Wolf wrote:
> Filipe dijo [Tue, Jan 22, 2008 at 08:44:57PM -0200]:
>>>> That is good!  I always would have liked for libactiverecord-ruby to be
>>>> separate from Rails.
>> Me too! But.. It would be interesting if rails source package provided
>> this package. Why don't you try to talk with rails package maintainer to
>> break rails package in many small packages, nd make rails depend on
>> them? This way things are beatiful.

On surface, yes it would look "nice". Underneath it would not accomplish
anything and just make more meaningless packages.

Rails is not just railties, but specific dependencies on specific
versions of activerecord, actionpack, activemodel, actionmailer and now
the activeresource (actionwebservice doesn't exist in new rails). This
is kind of similar to what happens with plone and its dependencies. If
you try using versions that are not from the same rails version, you are
asking for trouble.

The real problem is the debian's packaging environment which cannot
handle more than one version of a package installed at the same time.
This problem doesn't really exist with ruby gems, but that is geared
towards ruby only. So, packaging rails separately from activerecord
makes sense in the ruby gem world, but it makes less sense in the Debian
world. Essentially in Debian you end up with the same stuff installed if
you want to use rails. If you just want to use activerecord, you have to
install rails which gives you minimal disc overhead over "mutli-package
solution".

The only solution I can see that doesn't result in meaningless extra
packages is for rails to install the active_record and other libs under
/usr/lib/ruby/1.8 and then use a bunch of symlinks to recreate the
structure as used by rails. This would allow one to use active_record by
just
   require 'active_record'
instead of including the current rails path in the application. What do
you guys think?

Splitting the package into separate packages where rails would depend on
all of them seems a little meaningless to me. It would only result in
token disk space savings to select few people that only use
active_record and not rails. And if you can't spare 2M of disk space,
well, ruby may not be the best choice for the environment anyway.

- Adam

PS. For an example why splitting rails would not be a good idea see old
zope-cmfplone in Etch, and new zope-plone3. Look at the dependencies.
The package is A LOT cleaner now though it is about 10x the size. The
old way of packaging it caused all sorts of grief.




More information about the Pkg-ruby-extras-maintainers mailing list