Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

Emmet Hikory emmet.hikory at
Wed Aug 20 02:13:19 UTC 2008

Scott Kitterman wrote:
> For a legalistic reading of policy, I think there is nothing wrong with that,
> but how is a typical user of a gem going to know that if they install gem X a
> library used by gem Y, Z, and package A will be replaced/overridden?  As a
> practical matter I think this declares it all to be the sysadmin's problem
> without giving them a way to know what risk they are taking or how to manage
> it.
> As I said in an earlier message in the thread it seems very like Windows DLL
> hell.  Hopefully it will mature.  I doubt that as a distro we can do much to
> improve this where it is now.

    Indeed.  The use of gems in this way on an end-user system is
bound to create problems, of the same sort (as previously pointed out)
of end-user use of cpan, ezinstall or maven.  That said, policy
specifically doesn't forbid the use of such tools by end-users, and we
do have support for upstream behaviour for all of cpan,  ezinstall,
and maven.  Creating correct upstream behaviour for gems as well, in a
manner that doesn't damage the areas typically managed by the
packaging system, is a good thing.

    Of course, such support cannot be used to build policy-compliant
packages, and so any gem that is packaged and has dependencies will
require either a patched gem install to handle it, or an alternate
build system to be put in place.  Ideally, for a given release, all
interesting gems would be packaged and be immediately available for
use: further users would be encouraged to use the gems from the
repositories (as is done for perl, python and Java).


More information about the Ubuntu-devel-discuss mailing list