[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#293055: Progress with rails?



Hi Adam,

 > Yes. I will release something soon. (After I finish another software
 > project I'm working on). We are talking day or two :)

 Ah, that's good news.

 > >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 :).

 Uhm... I can understand the intention, but what gives me the creeps is
 not being upstream compatible.  What I mean is that according to
 rubygems documentation, you write this:

     require 'rubygems'
     require_gem 'foo'

 Even worse: gems require gems.

 IOW, this part of the FAQ:

    Q. It'd be nice to package code as a Gem, and then have it easily
    portable to many packaging systems (e.g. manual, RubyGems,
    dpkg/apt-get and other distro specific packaging). A quick glance at
    RubyGems suggests that installation of a package as a Gem requires
    all of its dependencies to be gems also (due to require_gem).
    Thoughts on this?

    A. It would not be too difficult to create a convertor to
    auto-generate dpkg or rpm files out of gems. It has been on the TODO
    list since day 1, but it hasn't yet made it to the top of anyone's
    priority list. Anyone who would like to do this for one or more
    packaging systems is more than welcome!

 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".

 > Maybe I'm not familiar with the way Perl works, but rails is a
 > complete framework. It is not a bunch of libraries that can be used
 > to do whatever. It is a highly integrated framework that becomes part
 > of each web application. If you are looking just for a bunch of loose
 > libraries, then PHP is a great tool.

 First of all, I don't care about the POS that's PHP.  I could write my
 own security holes if I wanted to, thankyouverymuch.

 Second, we are among developers, you can drop the marketing speak.

 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.

 Marcelo



Reply to: