Re: Bug#293055: Progress with rails?
On Mon, Feb 07, 2005 at 06:23:08PM -0600, Marcelo E. Magallon wrote:
> On Mon, Feb 07, 2005 at 06:11:51PM +0000, Adam Majer wrote:
>
> > It is not a gem that will be packaged. I got upstream source (from
> > tagged subversion - there doesn't seem to be access to actual source
> > otherwise), change a few things, like remove dependency on gems and
> > subversion stuff, and make a deb out of it.
>
> *That* is the point I can't get thru, by the look of it :-)
>
> Rails upstream is a gem (but there's a tar.gz). I'm not actually
> *that* concerned about rails, since most people using it do not seem to
> care about Ruby, or for that matter, programming. My concern wrt to
> gems in general is that code that reads like this:
>
> require 'rubygems'
> require_gem 'mygem'
>
> in a "Debianized gem", like the one you propose, becomes:
>
> require 'mymodule'
>
> That's what I meant by 'not source level compatible'.
That is IMO the whole (and maybe not the only) gem problem. It is meant
as means of easy distribution and packaging but the source is changed
for it. RPA (http://rpa-base.rubyforge.org/wiki/wiki.cgi) experienced
the same problems packaging rails, but they've split the whole thing up
and Rails and it's elements (active*) are seperately installable.
You live either in the Gem world or you do not?
> > Rails doesn't need gems for use.
>
> I had the impression that rake does require rubygems. Isn't that the
> case?
It runs separately as well.
> > Making ruby gems work on Debian is simply changing gems to install
> > things in such a way that they will not interfere with Debian.
>
> I'm not sure what you mean.
Me neither. Is the developer going to do that or the user? If the
latter is the case it will become a mess. If the developer is going to
strip the gem stuff (everytime) like pealing an egg so that gem is used
as it is meant to be (easy distribution).
> > I don't think gems are a Debian package yet.
>
> There's <41FA4661.4030804@debian.org> and
> <41FDAAA4.70502@sgtpepper.net>. I haven't had the time to take a look
> at Akira's dh_rubygems.rb (Arika, could you please drop the ".rb"
> bit?). That might as well address my concenrs.
Why?
> > But if and when they are, installed packages with gems should
> > probably end up in /usr/local prefix since gems are 3rd party and not
> > from Debian.
>
> Which kind of ends up in the same trouble as CPAN modules and Debian:
> CPAN upgrades a module because there's a Debian package installed but
> it's an older version, and when the Debian packages get upgraded, the
> change doesn't reflect on the system because the local path has
> precedence over the path that the Debian package uses [...]
I think this raises a problem among all larger scripting languages. They all
have a distribution system with a lot of libraries and programs in it.
Not all can be in Debian, so people might install a system like CPAN,
RPA, Gems to get libraries that Debian misses thereby superseding
Debian's work. That is a users choice but he might not know what he is
doing. I'm still thinking what to do about it in RPA.
Paul
--
Student @ Eindhoven | JID: paul@luon.net
University of Technology, The Netherlands | email: paulvt@debian.org
>>> Using the Power of Debian GNU/Linux <<< | GnuPG: finger paul@luon.net
Reply to: