Ruby on Rails support in Intrepid - call for reviewers and cheerleaders
Emmet Hikory
emmet.hikory at gmail.com
Wed Aug 20 03:13:19 BST 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).
--
Emmet HIKORY
More information about the Ubuntu-motu
mailing list