< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous (in thread)
N :the next (in thread)
|<:the top of this thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
Todd Benson wrote:
> On 9/15/07, Shot (Piotr Szotkowski) <shot / hot.pl> wrote:
>> hemant:
>>
>>> NOO _never_ install rubygems from apt tree, its broken.
>> Why not? I'm using them with great success. They land in /var/lib/gems,
>> I have /var/lib/gems/1.8/bin in my $PATH and everything works perfectly.
>
> Some get lucky. I've had nothing but heartache using the apt tree for
> Ruby. This comes up pretty often on this list. I'm kind of at the
> point now where I think your should do your own build from source.
>
> Todd
>
>
It's probably *better* with Gentoo than most other distros and it's
probably better with Ruby than some other packages with their own
repositories, but unless the distro (or someone outside) has put a
significant amount of effort into integration, you're right ... if you
want to run a bleeding edge Ruby and gems, you should nuke whatever's on
your distro, if anything, install everything in /usr/local from source
and from the gem repository, and lie to other packages expecting to see
/usr/bin/ruby when they install.
I went through this with R on CentOS 5. It's a big hassle. R is in good
shape on Debian, but only because there's a developer in the Debian
community that repackages R and the interfaces to contributed packages.
I never did get the fonts working in R, and I gave up on it.
Fortunately, I didn't need to load Ruby or gems on this machine. Or
stick with production stable tested configurations from the distro.