Marcelo E. Magallon 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.> >On the mailing list I saw two or three people working on rubygems > >packages, but from what I saw there isn't even a concensus on what > >the package should be called, even less about what it should do. > > > >Care to shed some light on this?
> Rails will not use ruby gems - it will be a native Debian package :).
My problem is that by packaging a gem as a regular package, you become
incompatible with upstream at the source level. Am I missing
something? Perhaps I don't understand what you mean by "native Debian
package".
Rails doesn't need gems for use. Upstream rails uses gems for easy installation and distribution, but Debian already has .deb for that.
That said, my mention of Perl was only because of policy. I was really
baffled when I read ruby-policy and I didn't really know what to do
with a gem in that context.
Think of Ruby like an OS, and then you get gems as packages.
Making ruby gems work on Debian is simply changing gems to install things in such a way that they will not interfere with Debian. But rails doesn't need gems. Gems are just used for distribution by upstream. Upstream also uses .tar.gz as well as source distribution.
I don't think gems are a Debian package yet. 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.
- Adam
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
