--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 07, 2011 at 12:22:08AM +0900, Phillip Gawlowski wrote:
> >
> > Also, I've been following this thread. I am still unclear as to why the=
re is
> > such a need to have a gem2deb translation. Wouldn't a better solution b=
e to
> > have a meta package for RVM =A0and let rvm with rubygems handle gems/ t=
heir
> > dependencies?
>=20
> 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).

Are you sure you don't mean "upgrade" and "dist-upgrade", rather than
"update" and "upgrade"?  All "apt-get update" does is update the package
index.  If you're familiar with FreeBSD, it's a bit like "portsnap fetch
update", but for DEB packages rather than for ports.


> >=20
> > The RVM metapackage could include all the major dependencies
> > that one would reasonably expect to run into with say the 100 most popu=
lar
> > rubygems.
>=20
> 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?

Even the number 100 is pretty arbitrary, and I for one wouldn't want all
the dependencies for the 100 most popular gems automatically installed on
my system anyway, because I won't need to install all of the 100 most
popular (or even 50 of them).  The idea of installing all the
dependencies for the 100 most popular gems on my system just because I
want Ruby sounds a lot like the kind of thinking that gives me a system
where I can't uninstall Evolution without breaking Pidgin (if I used
Pidgin).  The dependency definition philosophy of modern Debian (and
worse, modern Ubuntu) is an exercise in lunacy.

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]

--6TrnltStXW4iwmi0
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk3s/zMACgkQ9mn/Pj01uKXqYACghPNhBC+r7zhkFrvRs9ghJ+To
YjoAn3FOljc5U61V0QcmaUMaJziVsj8T
=c8U3
-----END PGP SIGNATURE-----

--6TrnltStXW4iwmi0--

On Tue, Jun 07, 2011 at 12:22:08AM +0900, Phillip Gawlowski wrote:
> >
> > Also, I've been following this thread. I am still unclear as to why the=
re is
> > such a need to have a gem2deb translation. Wouldn't a better solution b=
e to
> > have a meta package for RVM =A0and let rvm with rubygems handle gems/ t=
heir
> > dependencies?
>=20
> 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).

Are you sure you don't mean "upgrade" and "dist-upgrade", rather than
"update" and "upgrade"?  All "apt-get update" does is update the package
index.  If you're familiar with FreeBSD, it's a bit like "portsnap fetch
update", but for DEB packages rather than for ports.


> >=20
> > The RVM metapackage could include all the major dependencies
> > that one would reasonably expect to run into with say the 100 most popu=
lar
> > rubygems.
>=20
> 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?

Even the number 100 is pretty arbitrary, and I for one wouldn't want all
the dependencies for the 100 most popular gems automatically installed on
my system anyway, because I won't need to install all of the 100 most
popular (or even 50 of them).  The idea of installing all the
dependencies for the 100 most popular gems on my system just because I
want Ruby sounds a lot like the kind of thinking that gives me a system
where I can't uninstall Evolution without breaking Pidgin (if I used
Pidgin).  The dependency definition philosophy of modern Debian (and
worse, modern Ubuntu) is an exercise in lunacy.

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk3s/zMACgkQ9mn/Pj01uKXqYACghPNhBC+r7zhkFrvRs9ghJ+To
YjoAn3FOljc5U61V0QcmaUMaJziVsj8T
=c8U3
-----END PGP SIGNATURE-----