Re: RubyGems in Ruby HEAD
On 23/09/05, Lucas Nussbaum <lucas@lucas-nussbaum.net> wrote:
> On 22/09/05 at 16:47 -0500, mathew wrote:
> I think the solution to this whole flame war is to find ways to easily
> convert a gem to a {Debian,RPM} package, so packagers can package more
> apps more easily and provide packages for more ruby software than
> currently.
The problems with that are
* you are always going to lag behind
* it takes no account of multiple versioning which is an essential part of gems.
* there's no way to have 'gem install rake' know that rake was
installed by a .deb autogenerated from a gem.
Can't apt leverage rubygems instead of embracing and extending?
rubygems can't possibly know about every platform it could ever run on
- they've already done a lot of work to get it working on plenty of
different OSes - but the reverse does'nt have to involve a huge amount
of maintenance.
What are the technical issues involved to having apt-get (or dpkg)
simply call off to rubygems?
It strikes me that if such a mechanism were possible, it could be
reused by the Debian project to support other external package
repositories,
which would save a *lot* of work for all Debian packagers.
does anyone know of other operating systems that are able to delegate
package management in this way?
I know freebsd integrated rubygems into its ports tree recently, but
AFAIK that was an 'convert a .gem into a port' automated build, rather
than a "when I type 'apt-get install gem-foo, run 'gem install foo' "
delegation technique.
--
Rasputin :: Jack of All Trades - Master of Nuns
Reply to: