I had no problems.
It pretty much boils down to three steps:
- Install Ruby via deb.
- Install ruby gems using the instructions for installing ruby gems.
- Install rails and everything else via gems.
browse the following write-up:
http://brainspl.at/rails_stack.html
Follow the instructions for installing the Ruby deb, and a few others.
(You can do it all in one line)
Then follow the instructions to install rubygems.
(this is the same for Mac and Windows as in any Linux distro)
Then use gems to install rails. (This is the same in Windows and Mac
and any Linux distro)
(BTW: Instructions for Windows follow these three steps as well, but
the first is install Ruby with a Windows installer, install gems,
install rails via gems:
http://wiki.rubyonrails.org/rails/pages/RailsOnWindows)
Or go here:
http://wiki.rubyonrails.org/rails/pages/RailsOnDebian
There are several sets of instructions, depending of stable, testing,
whatever.
If you want a nice quick ref for debian:
debian reference card:
http://people.debian.org/~debacle/refcard/refcard-en-a4.pdf
On 5/1/06, Sean L. [email protected] wrote:
Follow the instructions for installing the Ruby deb, and a few others.
install rails via gems:
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
That won’t help you if you want Ruby 1.8.4, though.
I ended up using the “apt-get source ruby1.8” method from the testing
repository, and that worked well… but still, “apt-get install ruby”
should install the latest stable release of Ruby, in my opinion.
Wilson B. wrote:
That won’t help you if you want Ruby 1.8.4, though.
I ended up using the “apt-get source ruby1.8” method from the testing
repository, and that worked well… but still, “apt-get install ruby”
should install the latest stable release of Ruby, in my opinion.
That would be convenient… except for when the latest ‘stable release’
has a bunch of problems with other packages and doesn’t play nice. To
take a concrete example, 1.8.3 was the stable release for a while. That
turned out to be a stunningly bad plan. Filtering out that sort of
problem is in the purview of the distro maintainers - that’s precisely
why Debian (at least in theory) has Stable, Testing and Unstable.
The one and only problem I personally have with Debian is the dog-slow
release schedule, but that’s balanced by a completely predictable
package system - which in itself is worth its weight in gold. The Rails
community has been bitten by the release schedule particularly badly,
because Rails has exploded while Debian is in a pretty major lull
between releases. For what it’s worth, I think Ubuntu’s got it right
with its 6 month cycle. We often forget that Rails is, compared to most
of the contents of a distro, absolutely cutting edge stuff, and I’ve got
no problems making allowances for the fact that the feature set for my
chosen distro was frozen well before Rails 1.0 hit.
The fact that the Ruby universe doesn’t map well to the Debian package
set is unfortunate. Unfortunate, but hardly insurmountable - it’s just
not the sweet spot, just like legacy integration databases aren’t in
Rails’ sweet spot.
I do have a question, though: what makes RubyGems less suitable for
Debian than CPAN or PEAR? Are they equally damned?
On Mon, May 01, 2006 at 03:38:55PM -0400, Wilson B. wrote:
I ended up using the “apt-get source ruby1.8” method from the testing
repository, and that worked well… but still, “apt-get install ruby”
should install the latest stable release of Ruby, in my opinion.
The problem you’re having, from the look of it, is that you’re
installing
from Debian’s stable release. Just like Ruby’s stable release isn’t
going
to include new and untested stuff all the time, Debian’s stable release
isn’t going to include new and untested stuff all the time. Hence you
don’t
get new upstream versions into Debian stable releases, because (more
than
anything else) people need to rely on the stable version to be just that
stable. Not necessarily bug-free (any more than Ruby’s stable release
is
bug-free) but relatively unchanging.
For a good example of why stability is a good thing, look at Rails
itself.
The 1.0 stable release was good. The 1.1 stable release was also good
but it broke a lot of existing software, which relied on features only
present in 1.0. Both of these releases are stable, in and of themselves
(both are excellent software development platforms) but they’re
different.
If I’m targeting a particular stable release (Debian 3.1, in this
instance)
I really, really don’t want a new, different version of anything
ending up in there and possibly making my life unpleasant.
I know it’s not a solution to your problem, but hopefully it’s at least
an
explanation as to why the problem exists. A solution is to run
backports
(assuming they exist; I’m not sure whether or where there is pre-built
Ruby
1.8.4 packages for Sarge).
–
You have a 16-bit quantity, but 5 bits of it are here and 2 bits of it
are
there… and 2 bits of it are back here and 3 bits of it are up there.
The
C code to extract useful data had so many >> and << operators in it that
it
looked like the C++ version of “hello world”. – Matt Roberds, ASR
On May 1, 2006, at 2:16 PM, Matthew P. wrote:
release
isn’t going to include new and untested stuff all the time.
I’m hesitant to get involved, but I must admit I was appalled when I did
apt-get install subversion and it installed 1.1.4.
Now, don’t get me wrong. It’s free, and I’m not complaining for
something
that good and FREE.
However, I was surprised.
–
– Tom M.
I didn’t realize I opened up a Pandora’s box with my initial post
about Ubuntu and mongrel … 
At the end I managed to install what I needed under Ubuntu, but also
decided to attempt the same thing on another platform. I installed
everything under Fedora Core 5, and found things more straightforward
(using yum and a few online rpm repositories). I found the user
interface of Ubuntu very pleasant and coherent, but all in all Fedora
performed better from the point of view of a relative newbie who wants
to use rails.