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