We got some feedback on this topic from Jay Edwards and team @ Twitter.
(Thanks Brian for the link-up).
<Comment0>
Frankly, unless you've got the resources and desire to maintain current
Indiana packages for all available gems, I don't see that it makes much
sense to try and have a non-gem rails installation. People are going to
install what they need -- which means that people will be installing
gems. I think it's prudent to realize that if you have a non-gem rails,
people are still going to try and install ruby gems and do whatever they
need to do to make it work. IMO, it's much easier to just say "use
gems". There's also the case where heavy ruby shops are packaging their
internal software as gems.
Now, you could do something like dpkg-perl which is a Debian package
that trivially turns perl modules into debian packages. So, you could go
with a Indiana packages for rails and whatever other gems you feel are
important, and provide something like indiana-gem-pkg. You provide it
with the name of a gem, it downloads it from a gem repo, unpackages it,
repackages it as an Indiana package and then installs it.
</Comment0>
<Comment1>
Would
you suggest that the gem file s be stored in the gem repository so as to
be reusable by rubygems . . . or would this be a different installation?
I asked around the office. The consensus was that even if some form of
vendor packaged gems are supplied, they should be visible to ruby gems
-- that way if someone wants to "override" a packaged gem with a plain
rubygem, it wouldn't be a problem. Here's a quote:
"the bottom line is that if they're going to do their own package
management, it should be based off of the upstream package plus patches,
and should not conflict with gems.
i.e., if gems are installed, they override the system package. period."
</Comment1>
<Comment2>
> Now, you could do something like dpkg-perl which is a Debian package
> that trivially turns perl modules into debian packages. So, you could
> go with a Indiana packages for rails and whatever other gems you feel
> are important, and provide something like indiana-gem-pkg. You
provide
> it with the name of a gem, it downloads it from a gem repo,
unpackages
> it, repackages it as an Indiana package and then installs it.
You mean a invocation like "indiana-gem-pkg install rails"(or maybe
even "pkg install rails") would then proceed to install Rails?
Exactly. Use the existing global gem repositories, download the gem,
extract it, apply any desired patches, automatically repackage it as an
Indiana package, and install it as a system package. Or something very
similar.
</Comment2>
Dick Davies wrote:
> On Fri, Feb 22, 2008 at 3:31 PM, Prashant Srinivasan
> <Prashant.Srinivasan at sun.com> wrote:
>
>
>> Jyri Virkki wrote:
>> > Prashant Srinivasan wrote:
>>
>
>
>> > Debian seems to have achieved this so no reason OpenSolaris can't.
>> > gem-installed content goes under /var, package-installed content goes
>> > under /usr and they seem to coexist ok (I've played a fair amount
>> > with gem vs. packages on debian, but only at a shallow level. I urge
>> > you to experiment with it in more depth).
>>
>
>
>> Well, the Debian position is rather strong. They don't believe that the
>> gem format is ideal since it is not FHS compliant. They also disagree
>> with the concept of using "require_gem". So, if you're using Debian,
>> it's apt-get all the way, or rubygems all the way.
>>
>
> Using ruby (and rails) on Debian is a massive pain for me and a lot of
> other users.
> They've been quite insistent that they know what Ruby developers want
> and that apt is
> 'better than gems - see looong bunfights on ruby-talk mailing list/newsgroups.
>
> Debian IMO is a shining example of how NOT to handle Ruby packages, for all
> the
> reasons you listed in your mail.
>
> In a nutshell: it's a lot more work for you, and developers will curse
> you for it.
>
>
--
Prashant Srinivasan
F/OSS Enthusiast
Sun Microsystems, Inc.
http://blogs.sun.com/prashant
GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x82FBDE5A
