On Mon, Jun 6, 2011 at 4:28 PM, andrew mcelroy <sophrinix / gmail.com> wrote:
>
> Also, I've been following this thread. I am still unclear as to why there=
 is
> such a need to have a gem2deb translation. Wouldn't a better solution be =
to
> have a meta package for RVM =A0and let rvm with rubygems handle gems/ the=
ir
> dependencies?

Two package managers create double the work for maintenance, and
that's when the package managers are pretty much identical, not to
mention that "gem update" updates the release *and* the patchlevel,
while "apt-get update" only updates the patchlevel ("apt-get upgrade"
updates the release level).

And consider, for example, "gem install psych". It has an external (to
Ruby) dependency (libyaml.h), that RubyGems cannot satisfy without
creating loads of overhead, but "apt-get install libruby-psych" *can*.

> The RVM metapackage could include all the major dependencies
> that one would reasonably expect to run into with say the 100 most popula=
r
> rubygems.

And these 100 gems are a one-size fits all package? And I can't ever
get rid of them? Who's curating this list? Will it change when
something becomes popular? How is "popular" defined, anyway? And why
would I want a compiler on a webserver serving Rails apps? Is your RVM
meta-package locked down so well that nothing, ever, can use the
compiler for nefarious purposes? What about the 95 included RubyGems
that I don't use, yet are there and increase the surface of attack for
my server?

--=20
Phillip Gawlowski

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Leibnitz