Hi guys,
have you made any progress with the rails package? I have interest in
this application, but since I saw you working on it I haven't put much
time into a package.
I haven't figured out the rubygems thing. What I mean is that IMO Ruby
packages in Debian should work as far as possible as Perl packages in
Debian. From what I have seen after poking around rubygems, it creates
its own namespace (e.g. packages are installed under a directory that's
not in the defaul $:). Rubygems seems like a nice idea if you are
installing packages on your own, but rather inconvinient for a
distribution. My initial reaction was to bend rubygems to do the right
thing Debian-wise, but after reading ruby-policy I wasn't sure what the
"right thing" is. Contrast ruby-policy with perl-policy: ruby policy
allows for packages for different ruby versions to coexist (the
libfoo-ruby1.8 thing), which makes upgrades troublesome, there's a
mention of -ruby packages, but there's no policy on what to upgrade,
how to upgrade or when to upgrade; ruby-policy is not clear on what the
hash bang should look like ("you are free to" is not policy); there's
no clear distinction between architecture dependent and independent
modules; there's no rationale for the
/usr/lib/ruby/<X>.<Y>/<GNU-SYSTEM> thing; documentation policy is
absent; ruby followed the libfoo-ruby mistake and it isn't clear on
naming (e.g. is the proper name for Ruby on Rails "rails",
"rails-ruby", "ruby-on-rails", "ruby-on-rails-ruby" or what?).
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?
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
