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

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.

On 05:03 Sun 16 Sep , M. Edward (Ed) Borasky wrote:
> 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.
>
>

Symlink should work for any /usr/bin/ruby issues if you install is
locally.

But, on another note, isn't there a way to install gems for Ruby that is
fairly automated but distro-independent?

On Sun, Sep 16, 2007 at 05:03:07AM +0900, M. Edward (Ed) Borasky wrote:
>
> 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.

One of the things I like about *BSD, actually, is the tendency for
anything not in the base system to end up in /usr/local. This, combined
with the way everything is ultimately based on source distributions of
software and software management is basically built on the fundamental
tools that are available everywhere, adds up to a system that's really
easy to customize with software compiled from source and added into the
system oneself, without screwing up a package management system.

Your mileage may vary, but I've had really good luck with Perl and Ruby
modules on FreeBSD.


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

Everything should work swimmingly on Debian (most of the time, at least),
as long as you only want the version of Ruby currently in the package
repositories and don't need gems that aren't packaged for APT. If you
want a different version of Ruby or additional gems, however, you're
better off installing in /usr/local/bin rather than /usr/bin, as you
said.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Patrick J. LoPresti: "Emacs has been replaced by a shell script which 1)
Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk
quota by 100K; and 3) RUNS ED!!!!!!"

On 06:24 Sun 16 Sep , Felix Windt wrote:
> > -----Original Message-----
> > From: forgottenwizard [mailto:phrexianreaper@hushmail.com]
> > Sent: Saturday, September 15, 2007 1:55 PM
> > To: ruby-talk ML
> > Subject: Re: What Linux distribution to choose for learning
> > Ruby and Rubyon Rails
> >
> > On 05:03 Sun 16 Sep , M. Edward (Ed) Borasky wrote:
> > Symlink should work for any /usr/bin/ruby issues if you install is
> > locally.
> >
> > But, on another note, isn't there a way to install gems for
> > Ruby that is
> > fairly automated but distro-independent?
>
> The only universal approach is to download the gem source, build it and
> install it - that should work anywhere. Then you can install any gem
> directly via "gem install", though in some cases you may need the standard
> build chain, plus any libraries required.

gem install was what I was thinking of, actually.

I don't see why someone couldn't hack together a manager of some sort
for use if they wanted to.

> The main problem with that approach is that pretty much all distributions do
> not officially support any custom installed packages outside the packet
> management system. You will either lose the official support channels (think
> SuSE or RHEL) for the software, may have a harder time getting community
> support or may run into difficulties when updating/upgrading as custom
> compilation is outside the packet management system. This may leave behind
> files in unexpected places, change directory permissions, change
> dependencies or library versions etc.

True. Of course, this is also why people use chroots for testing.

> That is most unfortunate as the server distributions in particular often
> ship software several versions out of date for security or stability
> reasons, which can result in feature loss or unfixed bugs - RHEL 4.5, for
> example, still has Ruby 1.8.1:

Sounds like Debian...

> # ruby -v
> ruby 1.8.1 (2003-12-25) [x86_64-linux-gnu]
> # cat /etc/redhat-release
> Red Hat Enterprise Linux ES release 4 (Nahant Update 5)
> #
>
> Depending on your environment, this may be impossible to circumvent - in
> shared server environments, you may not have the necessary permissions/tools
> available, at work policies or SLA requirements may prohibit any custom
> installations. At my job, we only use Ruby interally to the engineering
> group, so we can get away with customization. If it were used in production,
> we'd be using whatever the official channels provide as our SLA states
> having to stay 100% within vendor supported options.

That I can understand.

> Felix

On Sun, Sep 16, 2007 at 07:48:25AM +0900, forgottenwizard wrote:
> On 06:24 Sun 16 Sep , Felix Windt wrote:
>
> > That is most unfortunate as the server distributions in particular often
> > ship software several versions out of date for security or stability
> > reasons, which can result in feature loss or unfixed bugs - RHEL 4.5, for
> > example, still has Ruby 1.8.1:
>
> Sounds like Debian...

Actually, I think Debian is using 1.8.5 currently on the stable version.
At least, that's what's on the Etch system I have in the corner, waiting
for me to copy a few files off it, wipe it, and turn it into some kind of
FreeBSD-based network appliance.

Sarge, on the other hand, is using 1.8.2. Of course, that's not even the
current Stable release, and is in legacy support right now.

I'm not sure what Lenny, the current Testing release, is using. I
haven't touched Lenny yet, since FreeBSD is my primary OS choice these
days.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Leon Festinger: "A man with a conviction is a hard man to change. Tell him
you disagree and he turns away. Show him facts and figures and he questions
your sources. Appeal to logic and he fails to see your point."

On Sunday 16 September 2007 01:29:12 Chad Perrin wrote:
> One of the things I like about *BSD, actually, is the tendency for
> anything not in the base system to end up in /usr/local. =A0This, combined
> with the way everything is ultimately based on source distributions of
> software and software management is basically built on the fundamental
> tools that are available everywhere, adds up to a system that's really
> easy to customize with software compiled from source and added into the
> system oneself, without screwing up a package management system.
>
> Your mileage may vary, but I've had really good luck with Perl and Ruby
> modules on FreeBSD.

This is true. I am often find my self using ports on FreeBSD where on=20
Ubuntu i have to use "gem install". Also on Ubuntu (Debian) rails goes to=20
one place, but gems to another and you'll see only gem docs in gem_server,=
=20
rather then all documentation on FreeBSD.

=2D-=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D =20
=2D Best regards, Nikolay Pavlov. <<<----------------------------------- =
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D =20

yo creo que eso depende de la persona mmm... por k puedes tener
diferente distribucion y en cualquiera lo puedes instalar ya sea suse
ubuntu, mandriva, fedora, todo depende de ti y cual te lata m=E1s yo
creo que loq ue si se debe de respetar es el entorno grafico que debe
ser nome, pues como ruby se mantiene en mac os gnome esta inspirada en
el XD yo voto por SuSe