I'm using Debian/Linux and have come upon tough rock while digging for
rubies. Debian, like most Linux distos, manages installed software with
a package management system. Ruby as well as several libs including
Rails, in particular, are available as packages. That's great as it is.
Nevertheless, of course there are libs that are not available as debian
packages, but are available as gems.
Installing RubyGems is quick and easy, but from there on, I'm stuck with
two problems:
* Files from gems are installed below /usr where they get intermixed
with files from regular debian packages. I'd much prefer gems being
installed below /usr/local.
* RubyGems does its own dependency management and is ignorant of
anything installed as debian packages. As an effect, when I try to
install a gem that depends on Rails, RubyGems wants to install the
Rails gem, even though Rails is already installed.
Is there a way to make these to package managers play nicely?
I'm using Debian/Linux and have come upon tough rock while digging for
rubies. Debian, like most Linux distos, manages installed software with
a package management system. Ruby as well as several libs including
Rails, in particular, are available as packages. That's great as it is.
Nevertheless, of course there are libs that are not available as debian
packages, but are available as gems.
Installing RubyGems is quick and easy, but from there on, I'm stuck with
two problems:
* Files from gems are installed below /usr where they get intermixed
with files from regular debian packages. I'd much prefer gems being
installed below /usr/local.
* RubyGems does its own dependency management and is ignorant of
anything installed as debian packages. As an effect, when I try to
install a gem that depends on Rails, RubyGems wants to install the
Rails gem, even though Rails is already installed.
Is there a way to make these to package managers play nicely?
Michael
I'm also grappling with this issue. For now, I'm using gems when the corresponding Debian package does not exist. As ruby grows more popular, I'm sure this strategy will rear its ugly head.
Maybe the best solution is to have a new tool that wraps both gems and the OS's package manager. This will allow gems to grow while ignoring the complexities of supporting apt, yum, etc. And it will allow the wrapper to add support for package managers other than apt.
Installing RubyGems is quick and easy, but from there on, I'm stuck with
two problems:
* Files from gems are installed below /usr where they get intermixed
with files from regular debian packages. I'd much prefer gems being
installed below /usr/local.
A libgems-ruby/rubygems package is currently in preparation (by Daigo
Woriwaki) and I am checking it out for uploading/sponsoring it.
There are however some outstanding issues (see your point below).
See also: http://lists.debian.org/debian-ruby/2005/01/msg00017.html
* RubyGems does its own dependency management and is ignorant of
anything installed as debian packages. As an effect, when I try to
install a gem that depends on Rails, RubyGems wants to install the
Rails gem, even though Rails is already installed.
I have not used Debian, but Gentoo packages could simply wrap gems, so
that when a package is installed, ruby-gems is used to grab the files,
and effectively both systems know about the package being installed.
Its much better than using yet another tool. Of course, this means that
all interaction with gems would be through portage. It should be possible
to auto-update the list of gems that portage knows about too, maybe
another little script could do that. A simpler way would be to just distribute
the ebuilds for each gem.
···
On 5/4/05, Friday <spamtrap@caretaker.dolphins.ch> wrote:
Michael Schuerig wrote:
> I'm using Debian/Linux and have come upon tough rock while digging for
> rubies. Debian, like most Linux distos, manages installed software with
> a package management system. Ruby as well as several libs including
> Rails, in particular, are available as packages. That's great as it is.
> Nevertheless, of course there are libs that are not available as debian
> packages, but are available as gems.
>
> Installing RubyGems is quick and easy, but from there on, I'm stuck with
> two problems:
>
> * Files from gems are installed below /usr where they get intermixed
> with files from regular debian packages. I'd much prefer gems being
> installed below /usr/local.
>
> * RubyGems does its own dependency management and is ignorant of
> anything installed as debian packages. As an effect, when I try to
> install a gem that depends on Rails, RubyGems wants to install the
> Rails gem, even though Rails is already installed.
>
> Is there a way to make these to package managers play nicely?
>
> Michael
>
I'm also grappling with this issue. For now, I'm using gems when the
corresponding Debian package does not exist. As ruby grows more
popular, I'm sure this strategy will rear its ugly head.
Maybe the best solution is to have a new tool that wraps both gems and
the OS's package manager. This will allow gems to grow while ignoring
the complexities of supporting apt, yum, etc. And it will allow the
wrapper to add support for package managers other than apt.