Re: RubyGems in Ruby HEAD
On 23/09/05 at 10:47 +0100, Dick Davies wrote:
> 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
Debian has stable, testing, unstable branches. Sometimes people want to
lag behind for stability/security reasons. And if it's easy to package,
the lag can be minimal.
> * it takes no account of multiple versioning which is an essential
> part of gems.
Debian packages have been having that for ages ... Dependancies on a
specific version, on > version, on < version, ...
> * there's no way to have 'gem install rake' know that rake was
> installed by a .deb autogenerated from a gem.
That's why gems should be avoided except for developers really knowing
what they do.
> 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.
What makes gem & ruby so special that they should have their own package
system ? I think having "apt-get install" call "gem install" is never
going to happen. With lots and lots of work, you could maybe convince
the debian-ruby people, but you will never be able to convince all
debian developers.
I don't think gem does everything APT can do. For example, if your gem
include a shared library written in C, does "gem install" compiles it ?
If so, it requires a compiler and a lot of -dev packages on the client
system. If the binary code is included in the gem, how will you compile
it for all Debian architectures, including stuff like hppa, m68k, or arm
?
And even if this is fixed (I don't see how), other issues will probably
be raised...
I think the efforts should be targeted at making it more easy to convert
gems to distribution packages, and making it more easy to follow
releases of new gems. This wouldn't be Debian-specific but would help
all Linux distributions.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: